Re: [Enigma-devel] crashes on linux gcc exception handling

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Daniel Heck" <address@hidden>
Cc: "Tacvek" <address@hidden>; <address@hidden>
Sent: Monday, September 25, 2006 6:25 PM
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling


> Hi,
>
> Daniel Heck wrote:
> > > So currently there are three types of errors:
> > > 1. Lua code internally raises an error. (Dispatch internally with
> > > longjmp or c++ exceptions. If not caught by internally with a pcall, is
> > > handed to Enigma which converts it to an exception and throws it.)
> > > 2. C code raises a lua_error. This is handled exactly like the above.
> > > 3. Enigma raises a C++ excepetion.
> > I only want to make sure that errors that could (or should) be handled
> > inside the Lua scripts _can_ be handled inside the Lua scripts.  For
> > example, GetNamedObject() should probably continue to return nil if it
> > is called with an unknown object name and not raise an error.  Error
> > handling inside the levels should not suffer from the fact that we start
> > to use exceptions more extensively inside the C++ engine.
>
> Agreed. For common uncritical errors that do not leave the engine in an 
> unconsistent state the usage of special return values is preferrable.

Special return types are certainly correct there.

If the error is uncommon, leaves the engine in a somewhat inconsistant 
state, or is semicritical,
but eveything needed to bring things back into a consistant state is 
available to
scripts, then using lua_error() seems right. pcall can be used by levels 
that wish to handle the error.

If a Lua script has no hope of fixing the error, then a C++ exception is 
definately correct.

Of course, the system used internally by Lua (longjmp or c++ exceptions) 
makes no difference to that.
Indeed it makes no difference at all except in the case of nasty bugs 
outside of Enigma.


> > > Note that this bug is affecting type 3 errors only. I suspect it is
> > > potentially possible to use only type 2's. That would solve the problem
> > > on Linux
> > > and would allow lua scripts to trap errors.
> > >
> > > The only downside is that a lua program would trap an error that it is
> > > incapable of handing. If it fails to rethrow the error in such a case it
> > > would be bad. It could either crash, or it could result in the usefull
> > > error message being replaced with a less useful one created by lua's
> > > internals.
>
> Currently only "enigma.SendMessage()" converts type 3 to type 2. With a 
> proper use of the catch-statement in luaconf.h and perhaps 2 different 
> runtime exceptions, one for fatal and one for uncritical exceptions, 
> Daniel's proposal should be feasible.

So what you are suggesting is 2 exception types. One that never unwinds over
Lua (barring a bug in enigma), but is converted to a lua_error. Lua then 
unwinds itself,
letting lua code have a chance to deal with the error. (The fact that lua 
would be using c++
exeptions here should not make a difference, except for the nasty bug) If 
the lua script does not
deal with the error, Enigma will get the error back, convert it back into an 
exception, which will
get caught in the exception handler that aborts the level and displays the 
message.

The other type of exception will normally unwind directly back to that 
exception handler.

As I see it, that first type of exception is only usefull if some c++ code 
wants a chance
to handle that error before the lua code. If no c++ code wanted to deal with 
that exception,
then Enigma could have simply used lua_error.

Is that all correct?

> > Agreed.  And I don't think there is any need for immediate action; but
> > error handling inside the level code is something we should definitely
> > keep in mind.
>
> O.k. - let us switch the configure option to enable-cxxlua as default for 
> all OS and keep in mind the possible improvement.

Ok.

Patch for that is attached. I tested all configurations so I'm pretty sure I 
got
it right.

The only problem is that tolua++ won't build under C++ (actually I almost 
got it to work, but because of the inclusion of the SDL cflags and libs in 
the default c++ cflags and libs, it would not quite build right when cross 
compiling.)

test.patch
Description: Binary data