[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: Ronald Lamprecht
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling
Date: Thu, 28 Sep 2006 23:04:34 +0200
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)


Tacvek schrieb:
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?

All with the following remarks to the last two sentences: Keep in mind that the usage of Lua is optional and thus no C++ engine code besides the functions in lua.cc should throw lua_error. Uncritical exceptions can be handled anywhere - before lua code, within lua code, or after lua code (before the final level exception handler).

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


Until you are able to deliver a patch for the tolua++ build, developers can compile it with "--disable-cxxlua" as I explained in "doc/README.mingw32".

- Ronald

reply via email to

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