Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Libraries using longjmp for error handling Date: Thu, 28 Sep 2023 18:24:28 -0700 Organization: A noiseless patient Spider Lines: 38 Message-ID: <86y1gphiur.fsf@linuxsc.com> References: <65SQM.565977$9o89.411905@fx05.ams4> <871qejf62x.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="13636bbb038e3a1f79d11dd50eec8409"; logging-data="4149754"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+eya+EYT1lr5UlffYDQz3XFGjaYOGJXR0=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Aea0aWnp2r6S6oWqHq1ukdoDajk= sha1:QVJEb/oWnd5aIxEtrhCbFinMUXc= Xref: csiph.com comp.lang.c:176692 Ben Bacarisse writes: > Johann 'Myrkraverk' Oskarsson writes: > >> On 9/28/2023 6:52 AM, Blue-Maned_Hawk wrote: >> >>> Personally, i think that, at least for a library, an error >>> should _only_ be communicated by return value. If more complex >>> information is required, then the return value can be made more >>> complex. > > ... > >> Error handling in libraries is a thorny subject, and I could go >> on a long rant on it. The short summary is simply this: error >> handling is rife with incompetence, and incompetent designs. >> Even in languages that ostensibly provide better mechanisms than >> C, the details are usually poorly documented and under-specified >> [1]. > > 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.