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

Here is a simple, thread safe and easy to use C way that I believe might be a better compromise.
This is actually 3 files mixed together (except.h, except.c and extry.c) but it will compile and run as is (for testing purposes of course)

Any way check it out, compile it then let me know what you think.

[EDIT] I attached a new version that does a lot of ascii->current text format conversions. I'm not sure if they would be necessary but it works just as well.

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.

There seems to be a question over whether setjmp/longjmp is actually safe to use with local variables lying around. As I understand it, local variables are supposed to be on the stack, and can be put into registers for speed optimizations. Since they're supposed to be on the stack, I'd think the compiler would be smart enough to not do anything dangerous around setjmp/longjmp that would compromise that (eg. copying vars from registers into the proper stack location before longjmp completes, and having the vars reloaded from the stack into the proper registers before setjmp returns non-0). Does anyone have any info that might clear this up?

Also another idea might be to include a C++ exception throwing callback for errors (eg. an error occurs, Allegro calls a callback, etc), and have an al_init option to use it by default. However, the issue with that seems to be thus:

• You need -fexceptions to be able to throw exceptions from C++, through C code, and back to C++, using GCC. Do other compilers support a similar option?

• MSVC vs GCC. Would throwing an exception from GCC-generated code through an MSVC DLL (or vice-versa) cause problems?

</li>

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

It's not a question. Try this program:

On my system, compiling with `gcc -O0' prints "0". Compiling with `gcc -O' or above prints "1". You really do need to declare `c' as `volatile'.

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

I'm not sure if setjump is thread-safe though. Imagine that multiple threads tried to use setjump at the same time. The results would then be undefined. After my previous post I searched through allegro.c and discovered that my code was very similar to allegro's ASSERT code. Maybe there could be a solution that would jump using a #define macro instead of calling a function directly.

[edit]
It's simple and pretty much the same is programming without AL_TRY but this way you get cleaner looking code with the c++ style you might be looking for.

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

One of the things I was going for was a clean code execution path. So you could run some code, if it errors, stop and run some cleanup code, then continue running code. eg:

al_audio_init();
al_create_voices();
if there was an error
{
   al_audio_close();
   warn("no sound!");
}

more_code_here();

Of course, if the first function fails, you don't want to run the second. But in either case, you want to run the same error handling code, then continue on whether there was an error or not.

As well, for newbies or someone who just wants to quickly get something down, you're not going to want or know to tediously check every function for errors, so having a simple way to automatically catch errors for you, at least in the beginning, would be very helpful.