Re: [AD] 4.3 error handling

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> On Wednesday 07 June 2006 22:03, Peter Wang wrote:
> > Any way you do it, it's not really *optional*, not if you want to write
> > Allegro code that works in all circumstances.
> 
> It's never fully optional when you're working with someone else's code. If you 
> aren't the only one handling Allegro's state, you have to play nice with the 
> other developers. That's just how things work.
> 
> > How so?  API1 and API2 are different libraries, not two functions of the
> > same library.  They each #define their own setjmp-based try-catch macros
> > which don't know about each other.
> 
> API1 has to know about API2 to be able to use API2.  And in knowing API2, it 
> should know how to handle its errors. Whether it's checking a return value, 
> or catching an exception, or whatever.

They are completely independent in my example, e.g. API1 = graphics
library, API2 = network library.  The _user_ is using both libraries,
but neither library knows or cares about the other.  Both have home-brew
exception-lookalikes: try1/catch1 and try2/catch2, which also are not
related at all.  Both are hacky setjmp-based systems.

> > > I mean, you use atexit() in
> > > Allegro because that's how libc handles extra calls for cleanup when it
> > > exits. You don't say "well, it was libc that caused the exit, so we
> > > couldn't clean up".
> >
> > I don't understand.
> 
> Allegro (API 1) uses libc (API 2). When libc (API 2) errors in Allegro (API 
> 1), it has to be prepared for it. This can be checking the function's return 
> value, then cleaning up as needed (like with using open() to create a 
> PACKFILE), or setting up atexit handlers so it'll clean up properly if it 
> quits unexpectedly (like with assert).

Ok, I just didn't explain my example properly.


I need to stop being distracted by this discussion, so here's my final
thoughts on the matter:

What I'm saying is that custom setjmp-based exception systems don't
_compose_.  It really needs to be a standard part of the language.  If
you must, fine, add a mechanism to let C++ users make Allegro throw a
C++ exception[1].  If you really must, expose a setjmp/longjmp
interface.  But do NOT try to make it look like a try-catch system
because they are only superficially similar.

Even if Allegro is the only library to use such a system, it's too easy
for a user to assume Allegro's "exceptions" have the same semantics as
exceptions in some other languages (which are already hairy enough).
Trying to make it optional makes it worse, for developers, addon
writers, even users.

[1] internally, Allegro must propagate error codes up until the "top"
layer before throwing an exception so that internal cleanup code still runs.

Peter