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

[Daniel Heck]

Hi,

> 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.
> 
> For all of those the end destination is a c++ error handler that aborts
> the level and prints the message. Except: Lua code can trap types 1 & 2
> using pcall. [I'm not aware of any levels that do, but it is certainly
> possible].
> 
> Daniel is proposing that at some point we convert some of the type 3's
> into type 2's if appropriate. Obviously if the problem could not
> possibly be handled by a lua script there would be no good reason to
> convert a type 3 to a type 2.

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.

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

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.

- Daniel