Re: [AD] 4.3 error handling

[Chris <chris.kcat@xxxxxxxxxx>]

On Wednesday 07 June 2006 20:40, Peter Wang wrote:
> On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> > 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.

Could always do a push/pop stack. Push the current throwing state, change it 
and play with your code however much you want, then pop it before returning. 
Any other type of configurable error handling would require a similar method. 
And unconfigurable error handling is something that should be delegated to 
extremely serious unrecoverable errors (eg. SIGKILL).

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

That's just sloppy. API1 should properly handle API2 with it's error handling, 
otherwise you shouldn't be using API2 from within API1 (you should not use 
something you don't know how to handle properly). 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".