Because SF is giving problems with the mailing list, and I could always use more feedback, I thought I'd toss up my idea about error handling in 4.3 here.

My initial email follows (with [code] blocks added for your sanity )

sound_driver = al_audio_init_driver(NULL);
/* Allegro will have SIGABRT'd by now if there was a problem,
   we can continue assuming everything's okay */
..more game code..

al_error_try (
   sound_driver = al_audio_init_driver(NULL);
   ..more related code..
}
al_error_catch {
   AL_ERROR_ENUM code = al_get_last_error();
   /* We only handle invalid parameter errors */
   if(code != AL_INVALID_PARAM)
      al_error_throw(code);
   show_my_error("Could not init sound!");
}
..more game code..

al_error_disable_throws();

sound_driver = al_audio_init_driver(NULL);
if(!sound_driver)
{
   AL_ERROR_ENUM code = al_get_last_error();
   if(code != AL_INVALID_PARAM)
   {
      al_error_enable_throws();
      al_error_throw(code);
   }
   show_my_error("Could not init sound!");
}

al_error_enable_throws();
..more game code..

After this, Elias responded:

To which I responded:

But Allegro doesn't use C++. Since Allegro is going to use C (AFAIK), or at least expose a C-only API, it wouldn't be able to properly throw real exceptions.

Besides, with the way that code is, you can use any of the three at any time. Don't want to use the try/catch defines? Then just call al_error_disable_throws() once at the beginning of your program and don't think anything of them (just be sure to check for failure return codes). Too lazy to do your own error checking? Leave throws enabled and don't worry about the try and catch defines.

There's many times I wish I could just execute a string of commands and not have to check the return code of each one individually. But I'd still like to be able to handle the errors manually myself, without having to use a seperate callback function. Something like:

Having to check each function in that try block manually and basically call the same error-handling code would be very wasteful. And putting those few lines into a seperate function to install as a callback temporarilly would not be very clean (plus the trouble of being able to save and restore a previous callback, if one was installed, and optionally continue from outside of the "error zone").

NOTE: The al_get_error_string function I threw in up there isn't in the code I posted, but it would be useful to have a human-readable string of the problem along with a simple error code.

A C++ wrapper could still raise real exceptions:

al_audio::init()
{
   al_error_try {
      driver = al_audio_init_driver(NULL);
   }
   al_error_catch {
      throw al_get_last_error();
   }
}

That also has the benefit of leaving the real throwing in C++, so you needn't have to worry about C++ exceptions through C.

Then that's all you have to use. Just call al_error_disable_throws() and do it the C way.

My code has the benefit of being able to turn such aborts on and off at will. Like, say, if you want to init video without doing specific error checking, but then check the errors while initializing sound. It's also transparent, so you could put in a single try/catch around the whole initialization section without having to change the initialization code itself.

Then, again, you're free to use it. Nothing's forcing you to have to do it the first or second way.

It might be a good idea to use that anyway, for uncaught errors (eg. if an error is generated and either throws are disabled, or not within a try block). The error handler can then return non-0 to tell Allegro to clean up and SIGABRT, or 0 to tell it to keep going. Though it probably shouldn't be allowed to keep going if throws are enabled.

Allegro knows best how to clean itself up (as long as it can keep track of its
own state, anyway). There should always be a way to tell Allegro to exit
cleanly now, and raise a signal for debuggers.

That said, however, I do see a small problem with my code. You wouldn't be
able to jump out from the try block (via goto, a caught exception, another
longjmp, etc) and continue using Allegro code, or else the code will throw to
the wrong setjmp point later on. Though I don't think it's that big of a deal
to simply note that you can't do that, if something like this is used. You
could always throw a custom allegro error in the try block and check for it
in the catch block, where you can jump out however you want.
</quote>
That second message hasn't made it to the SF mailing list yet (despite the fact that I sent it over 13 hours ago and counting ).

I dont really see how that helps. What if you want to perform some cleanup at the end of a block of code?

FILE * f = fopen( "foobar" );
try{
  method1(f); // could throw error
  method2(f); // could throw error
  method3(f); // could throw error
  return f;
} catch ( whatever ){
   fclose( f );
}
return NULL;

How can you emulate that by putting a TRY{} thing around each statement? The point is to put all of the error code in one place.

I've always been suspicious of libraries that try to over extend the language into something it's not. I think if someone really wants exception handling, they should use C++ and a wrapper over Allegro that provides that. And yes, I realize that doesn't help out people writing core Allegro routines.

But if your proposed system did work on every compiler under all situations, I wouldn't see any harm in it. I'd still think it didn't belong, but I'm not the one writing code...

Of course, if allegro were to use c++, this whole chain of arguments would be a nonissue. (Or better yet, the core allegro code is in C, then a C++ wrapper is written to interact with the "core" (Depending on design, one could even write a C wrapper as well that abstracts some of the technicalities away from the core)). So, you basically make the core library require as verbose of arguments as possible (don't assume things based on previous settings and such unless the function's nature requires it), and write wrappers to abstract things away from the complicated core library (so, for example, in the core library, you might only have one version of create_bitmap, that takes width, height, and color depth arguments. The wrapper library can handle global colordepths externally to the core library).

Which is why the OP suggested TLS (thread local storage, aka __thread) allong with set/longjmp.