Re: [AD] 4.3 error handling

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> 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 way you do it, it's not really *optional*, not if you want to write
Allegro code that works in all circumstances.  So you'd need to cater
for *two* error handling strategies, not one.

> > 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, 

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.

> otherwise you shouldn't be using API2 from within API1 (you should not use 
> something you don't know how to handle properly).

So the user can't use the two libraries together?

> 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.

Peter