Re: [AD] 4.3 error handling

[Victor <vwss1984@xxxxxxxxxx>]

(Sorry about my poor english, a bit long e-mail follows up)
Well, i've read the thread only superficially, but let me intromisse
here...

Write a allegro C++ wrapper wouldn't be THAT difficult as someone
already pointed here. Some people already tried that but this doesn't
got anywhere not just because it would be too simple, hard to maintain
or something like that. Mainly because mostly of the allegro
contributors won't see it in the vanilla distribution (and as normal
humans could forget about that frequently until goes completely
obsolete). Newbies wcould not even know about their existence (i knen
about AllegroGL just about one year after starting with allegro).
BTW there is already some of C++ wrapping in allegro about the fixed
point type/class. If something is in vanilla allegro it probably will
be maintained easier as the maintainers work in all the library (or at
least it is less likely to be forget). Of course, we shouldn't
overbloat allegro, but IMO this doesn't like as a overbloat. However,
this is not the point of my idea here, i'm just suggesting that the
wrapper being in the vanilla distribution won't be bad.

About exceptions:

We could use setjmp() and longjmp() to emulate exception handling in C,
but as i'm seeing this would create more problems than solving. Other
ideas would be about creating weird macros to simulate that, but this
could be even worse. So, i thinked about that and i propose a idea:

First, allegro would use a sybol called ALLEGRO_USE_EXCEPTIONS (which
should be enabled only when combined with __cplusplus). Lets define a
struct (yes a struct, not a class) called AL_EXCEPTION or whatever like
that and some functions to handle it:

typedef struct AL_EXCEPTION
{
  char *description;
  struct AL_EXCEPTION *next;
  /* Other stuff that would be useful. */
} AL_EXCEPTION;

AL_EXCEPTION *_al_exception_list = NULL;

void al_make_exception(char *desc)
{
  AL_EXCEPTION *x = (AL_EXCEPTION *) malloc(sizeof(AL_EXCEPTION));
  ASSERT(x)
  x->desc = desc;
  x->next = _al_exception_list;
  _al_exception_list = x;
}

/* More API function to handle exceptions goes here. */

#ifdef ALLEGRO_USE_EXCEPTIONS
  #define ALLEGRO_THROW(x) throw _al_exception_list
#else
  #define ALLEGRO_THROW(x) return (x)
#endif

The AL_EXCEPTION is just a struct which is a simple FIFO linked list.
The function al_make_exception(char *), would insert exceptions in a
global pointer exception list (i know that _al_exception_list being
global is bad, but initially lets think about it as a global initially
to keep my idea simple). About that ALLEGRO_THROW, i will explain it
below.

In the deeps of the allegro library we could make something like:

int some_function()
{
  /* Code, code, code */
  /* Code, code, code */
  /* Code, code, code */

  /* Something goes wrong here. Lets throw a exception. */
  al_make_exception("Error description here");
  ALLEGRO_THROW(-1); /* Or whatever value which indicates a error. */
}

Notice that ALLEGRO_THROW. It could expand to a native C++ throw or to
a normal return statement as always.

So the user could do something like:

#define ALLEGRO_USE_EXCEPTIONS
#include <allegro.h>

// The program goes here. It's a C++ code.

int some_user_function()
{
  try // This is a real native try.
  {
     // Blah blah blah
  }
  catch (AL_EXCEPTION *error) // A real native catch.
  {
    // Handle the error here.
  }
  catch (SOME_USER_DEFINED_ERROR error) // This is very nice, isn't it?
  {
    // Handle the other error here.
  }
}

Now, lets see the PROS:
1. This thing don't introduce any hard try-catch emulating complication
to existing or new C code. Since the try-catch would be real one, we
don't need try fancy things to emulate it since we don't need to
emulate at all.
2. It allows allegro thowing real exception without breaking
compatibility (or at least this would be minimum).
3. Who don't like or don't/can't use the exception handling will be OK.
Even in C++ nobody would be forced to use that. The user will use it
only if he/she explicitilly says that.
4. We will get a exception list, allowing exception chaining even if
not using C++ nor simulating try-catch.
5. If the user makes something bad with _al_exception_list then it
isn't sloppy code, it is really bad code, and (as someone said) bad
code is bad code. I think that wouldn't be hard to encapsulate this
too.

Now the CONS:
1. This _COULD_ double allegro creating something like an allegro++,
not something terrible, but the library would need to be compiled twice
and in Windows could create something like alleg43.dll and
allegpp43.dll (or something like that). In Linux we would get something
similar. In this case, instead of #define ALLEGRO_USE_EXCEPTIONS, the
user would use #include <allegropp.h>
2. Would need some time to implement the exception-handling features in
a secure bug-free way and make all the library using that. But 4.3 (or
maybe 4.4?) will get an entirely new API...
3. When the user need to mix code with and without
ALLEGRO_USE_EXCEPTIONS, this could be really difficult. Could be worse
if this forces he/she to use two DLLs (if we can put it in all one DLL
then this problems goes off).

Victor Williams Stafusa da Silva

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/