Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #176735

Re: Libraries using longjmp for error handling

Show all headers | View raw

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>

[..how should errors be handled..]

>>> If it's done well, the result is not even "error handling" -- it's
>>> just what the function returns.  For example, a lookup in a table
>>> of integers in Haskell returns a type that is, in effect "maybe an
>>> integer" The return will be either "Nothing" or something like
>>> "Just 42".
>>
>> In languages that support it this approach is a good way to deal
>> with cases like this, I agree.  But to me it falls in a different
>> category than error handling.  An error condition is something
>> like an allocation (eg malloc()) failure, or a broken pipe.  Not
>> finding something in a table means whoever was responsible for
>> adding things to the table didn't add it - in other words it was
>> entirely a consequence of events that are under the program's
>> control.  The issue is how to deal with an unpredictable, and
>> usually very rare, event that is not something the program has
>> control over.  Typically these kinds of situations need a
>> different sort of mechanism than loading up the return value
>> of every function call.
>
> I agree that table lookup is not a compelling example, but I don't
> agree that anything different is needed.  I intended the idea to
> be generalised to have return values used for all error
> conditions.  There may be situations where something different is
> /better/, but I remain sceptical of even this claim.  Note I am
> not talking about situations where asynchronous errors need to be
> reported.
>
> C uses null pointers for this all the time.  Returning a null
> pointer is just a way to signal an error through the return value.
> In a language like C without null pointers I would want malloc to
> return a 'Maybe' type.  And for when more information is wanted
> (like your example of a broken pipe) the type returned from write
> should be a number of bytes or an error value of some sort.
>
> Obviously it's hard to recommend this in C since the language
> can't really express the patterns needed to make it convenient,
> but I think we are talking more generally here.

I acknowledge your statement about not considering asynchronous
errors.  My own comments are likewise.

I agree that all unusual result circumstances (which might be
labeled "error conditions", without meaning to prejudice the term)
can be handled locally via either compound return values or multiple
return values (eg, by using pointer parameters), or a combination of
the two.  In languages that provide good support for compound return
values, which I would say C does not, probably a single return value
(which is perhaps a compound value) always suffices, but I haven't
thought very carefully about that.  But I think we are in general
agreement that it's always possible to handle error conditions via
local return values.

Where we might not agree is whether using direct return values is
always a good choice.  In my view, sometimes it is, sometimes it
isn't - it depends on the particular situation.  That is definitely
the case for C, but I think also for other programming languages
that have better support for multiple return values or compound
return values, or both.  And certainly if needing other mechanisms
is true for languages in general then it we would expect it is true
for C.

> How would you prefer these sorts of thing to be signalled?

Let me give just one example.

kI wrote some code not long ago to add a value to a set of values,
where the set is represented using a recursive binary tree structure
(like red-black trees, but a little different).  Usually we may
expect that a request to add a value would offer a value not already
included in the set, but certainly it can happen that there is a
call to add a value that is already included, in which case the top
level return value should be the original tree structure.

I thought it would be easier to write a simple recursive routine
that assumes the to-be-added value is not yet included in the set,
and if that assumption is violated raise an exception that is caught
at the outermost level and simply returns the original argument tree
value.  Certainly the code could have been written to handle the
already-present situation at each level of the recursion, but it was
much easier and much cleaner to handle it by raising an exception.

That example doesn't translate to C in any obvious way, because C
code to add items to a set would very likely be written rather
differently.  I think it's harder to make use of non-local returns
in C than in many other languages, because C requires more thought
and discipline to set that up.  At the same time, when I look at C
code that tries to handle all exceptional conditions locally, I
can't help but think the code would be simplified overall if code
for dealing with exceptional conditions could be removed in the code
generally and instead used a different mechanism, in fewer places,
and perhaps similar to raising an exception, to handle such cases.


> BTW, have you come across Icon?

I have, and it's a fascinating language.

> It takes an intriguing approach
> where every operation succeeds or fails as well as having a value.

I have heard Icon characterized as saying "it tries to succeed",
and I think that's a fair description.  The idea of integrating
a backtracking engine into the language semantics deserves more
attention than I think it has been given, which is unfortunate.

> This idea is heavily built upon to produce a very comfortable
> scripting language.

My experience with Icon is purely academic, which is to say I have
read about it but never used it.  I have more experience with
Prolog, which is similar in some ways (notably backtracking) but of
course very different in other ways.

I'm intrigued by your comment that Icon makes a good scripting
language.  Maybe I don't understand what you think makes a good
scripting language, or even what "scripting language" means.
That subject is not topical in comp.lang.c, but I also peruse
comp.lang.misc and comp.programming if you wouldn't mind
continuing there.  Also you are welcome to send me an email
at this address if you would rather do that.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Libraries using longjmp for error handling (was: Re: More on NNTP testing) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-09-27 22:52 +0000
  Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2023-09-28 08:19 +0800
    Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 02:18 +0100
      Re: Libraries using longjmp for error handling Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-09-28 22:30 +0000
        Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 22:33 +0000
          Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 01:41 +0300
            Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 23:45 +0000
          Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-28 17:35 -0700
            Re: Libraries using longjmp for error handling David Brown <david.brown@hesbynett.no> - 2023-09-29 16:49 +0200
      Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 18:24 -0700
        Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 03:19 +0100
          Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 07:46 -0700
            Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 21:02 +0100
              Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 21:56 -0700
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 00:06 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 20:35 -0700
                Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 14:44 +0300
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 15:45 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 09:28 -0700
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 20:49 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-02 02:31 -0700
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-02 23:55 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 05:01 -0700
            Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 23:58 +0300
              Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 02:52 -0700
                Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 14:33 +0300
  Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:48 +0100
  Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 05:11 +0000
    Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 06:26 +0000
  Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:02 +0300
    Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 14:44 +0100
      Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 18:31 +0300
        Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 16:43 +0000
          Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 17:00 +0000
            Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:16 +0000
            Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 19:38 +0100
          Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 16:05 -0700
            Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 00:26 +0000
              Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 23:20 -0700
            Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-28 18:31 -0700
              Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 03:24 +0100
                Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 03:12 +0000
              Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 22:45 -0700
                Re: Libraries using longjmp for error handling Spiros Bousbouras <spibou@gmail.com> - 2023-09-29 12:02 +0000
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 08:10 -0700
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 17:03 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 10:15 -0700
                Re: Libraries using longjmp for error handling gazelle@shell.xmission.com (Kenny McCormack) - 2023-09-29 17:17 +0000
                Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 18:53 +0000
                Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 18:11 +0300
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 10:20 -0700
                Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-29 11:30 -0700
                Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 18:31 +0000
        Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 19:27 +0100
          Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 20:24 +0000
            Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 22:23 +0100
              Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 15:43 -0700
              Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 23:11 +0000
                Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 17:23 +0300
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 08:19 -0700
        Re: Libraries using longjmp for error handling David Brown <david.brown@hesbynett.no> - 2023-09-28 21:57 +0200
  Re: Libraries using longjmp for error handling Richard Kettlewell <invalid@invalid.invalid> - 2023-09-30 09:37 +0100

csiph-web