Re: [AD] 4.3 error handling

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> On Wednesday 07 June 2006 18:48, Peter Wang wrote:
> > That's just what you get for using a C library.
> 
> Which is, IMO, silly to be left without when something can be done about it. 
> If something works in a language using standard language functions, and such 
> a thing could prove useful, why not use it?
> 
> > > If it's optional, you don't have to use it. It wouldn't effect your code
> > > at all.
> >
> > But I still need to think about it and it looks like a mess.
> 
> al_init(AL_NO_ERR_JUMPS);
> 
> That's it. That's even assuming it's on by default, and you don't need to pass 
> a flag to turn it on.

What happens if I write an Allegro addon that uses the try-catch
mechanism, but the user's application does not?  And vice versa?
The more optional things and configuration possibilities, the more
problems like this that crop up.  Consider how much of a pain it is to
write proper Allegro addons which cater for different string encodings.

> > > (To note, I'm not saying this should move to C++. I'm just saying don't
> > > be surprised when people start trying out clever "tricks" to get added
> > > functionality. And when such "tricks" work, I don't really see a problem
> > > with using them)
> >
> > If people want to pull tricks in their own applications, fine, but
> > enshrining such tricks in an API is not a good idea.
> 
> I wouldn't really consider the basic concept a trick though. The very first 
> line in the man page description for setjmp/longjmp is this:
> 
> "setjmp() and longjmp() are useful for dealing with errors and interrupts 
> encountered in a low-level subroutine of a program"
> 
> This is exactly what it's being used for.

Because you can end up bypassing a lot of cleanup code, setjmp/longjmp
should remain in the realm of "last resort" and definitely not exposed
to the user, even through macros.  As soon as two libraries tried to use
setjmp for error handling, you're stuffed.

Peter