Re: [AD] 4.3 error handling

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2006-06-05 at 03:00 -0700, Chris wrote:
> While playing around with the sound code again, I thought it'd be nice if it 
> had some error handling abilities. I came up with this in about 15 to 30 
> minutes. I was just wondering if this is a good direction to put it in, or if 
> you wanted something else. Here's the main code:
> 
[..]
> 
> 
> So, what do you think? I kinda like it, but it may be too hacky for some 
> people's tastes. I believe it's logically sound though, so it shouldn't cause 
> problems..
> 

I think, for C code, those #defines are really ugly.. at least to me
they do look ugly. If I wanted to use #2, then I would use C++, not C.

And actual C++ users wouldn't benefit from setjmp/longjmp and those
#defines, since real exceptions should be raised for C++. I'd say, the
best idea for C++ is a wrapper, where al_sound::init would raise an
exception.

The TLS error code and NULL return is all that seems needed to me for C.
For the #1 approach, we could have a flag to al_init, like
al_init(ABORT_ON_ERROR). And then Allegro would automatically abort on
error - just like in your code.


The #3 approach looks much simpler than the #2 approach to me anyway, so
I don't think anything is wrong with it :)


One idea similar to setjmp/longjmp might be an error callback, something
like:

void al_set_error_callback(void *(user_error_handler)(AL_ERROR error));

Users could set it to their own function, and it gets called with the
error code. That way, it would be possible for users to use
setjmp/longjmp inside the callback if they so wish (I think at least, I
never fully could grasp how setjmp/longjmp works), or also raise C++
exceptions (unless, C++ exceptions can't be raised from a C callback, I
remember something in that direction). Or they could simply have abort
in there, then we wouldn't even need an extra flag for it in al_init.

-- 
Elias Pschernig