Re: [AD] 4.3 error handling

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> On Wednesday 07 June 2006 19:41, Peter Wang wrote:
> > What happens if I write an Allegro addon that uses the try-catch
> > mechanism, but the user's application does not?  And vice versa?
> 
> I thought about that. And I've implemented al_error_throws_are_enabled (name 
> subject to change :P). You could save that value before setting the mode you 
> want, then check it before you exit out of your code.

Horrible stuff.

> > > "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.
> 
> This method of using setjmp/longjmp makes it easier to handle cleanup code, by 
> making sure you get back into your code at a specific location if an error 
> occurs. And setjmp stores the state/position in a local (to the library) 
> variable. A library setting a jmp_buf variable wouldn't effect another 
> library setting another jmp_buf variable.

That's not what I was thinking of.  Let's try an example:

    try2 {
	try1 {
	    api1a();
	    api2(); // API2 exception thrown here
	    api1b();
	}
	catch1 {
	    cleanup1();
	}
    }
    catch2 {
	cleanup2();
    }

cleanup1() is not run because API2's home-made exception system
doesn't know anything about the API1's home-made exception system.
I know you *could* write the code in such a way that it works, but it's
not obvious that there is a bug lurking in there.

Peter