[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tacvek
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling
Date: Wed, 27 Sep 2006 20:13:53 -0400

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


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

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.


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

Attachment: test.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]