Re: C++, pcall, and yield

["Greg Falcon" <veloso@...>]

On 4/18/06, Mike Pall <mikelu-0604@mike.de> wrote:
> Greg Falcon wrote:
> > IMO, Lua really ought to be fixed to use catch(struct lua_longjmp)
> > rather than catch(...), since lua_longjmp is the only type of object
> > Lua will throw.  Lua has no business catching other exceptions.
> > Better to let unhandled exceptions remain unhandled.
>
> But then Lua can't restore its own state. See the (status != 0)
> cases in LuaD_pcall or lua_resume. So a catch(...) may be ugly,
> but at least it doesn't screw up the Lua state (with the
> LUA_ERREXC bug fix of course).

Interesting.

I'd like to throw the following alternative out there:

#define LUAI_TRY(L,c,a) try { a } catch(lua_jumpbuf&) \
        { if ((c)->status == 0) (c)->status = -1; } \
        catch(...) { /* possibly cleanup and call panic first? */
exit(EXIT_FAILURE); }

My fear with catch(...) is the presence of an (otherwise) unhandled
exception implies the very real possibility that the host application
is now in an inconsistent state.  Code has branched in a way the
author did not anticipate for reasons Lua cannot understand; Lua can
fix its state but cannot fix the application's.

Dissapointingly, catch(...) in the MSVC compiler will catch things
like null pointer accesses and segfaults (always in older versions and
based on compiler flags in newer ones, IIRC).  Continuing on in the
face of that sort of error always worries me, so MSVC is where I
gained my deep distrust of catch(...).

The good news is that this is highly localized luaconf.h stuff.  Part
of me feels like a LUA_ABORT_ON_UNHANDLED_EXCEPTION compile-time flag
might be appropriate, but it's hard to imagine bloating luaconf.h for
such a small issue.

Greg F