Re: [AD] 4.3 error handling

[Chris <chris.kcat@xxxxxxxxxx>]

On Wednesday 07 June 2006 23:52, Peter Wang wrote:
> They are completely independent in my example, e.g. API1 = graphics
> library, API2 = network library.  The _user_ is using both libraries,
> but neither library knows or cares about the other.

As they shouldn't. A graphics library wouldn't call network functions, and 
vice versa. I don't see what the problem is. The graphics library would jump 
to its catch on error, and the network lib would jump to its catch on error 
(just like using C++, the libs would/should throw an object of a type 
specific to their libraries). You just need to make sure that regardless of 
whichever one it jumps to, it cleans up all relevant code.

eg:

try1 {
   api1a();
   try2 {
      api2();
   }
   catch2 {
      api1_throw();
   }
   api1b();
}
catch1 {
   cleanup1();
   cleanup2();
}

Or alternatively, disable API2's throwing and check its return value manually 
(something you can't do with C++ exceptions). Whichever you want.

> If you really must, expose a setjmp/longjmp
> interface.  But do NOT try to make it look like a try-catch system
> because they are only superficially similar.

The way I see it, 'al_catch' is pretty much 'catch(AL_ERROR err)' in C++; just 
without the implicit variable creation. It wouldn't catch anything other than 
an Allegro error, which can only be thrown with 'al_throw(err);' (which would 
be 'throw (AL_ERROR)err;'). As such, something like

throw "foo"; /* a non-Allegro throw */

would never be caught by

catch(AL_ERROR err) /* al_catch */

because it's not the same type. Just make it a point to note that Allegro's 
exceptions aren't C++ exceptions and can't catch them, and vice versa.

But, as I said, I'll concede that trying to make it look like C++ try/catch 
*may* be a bit too much. A less transparent method would be acceptable (as 
long as it's not /too/ opaque :P). But the basic idea is a good one, IMO, and 
should be considered.