lua-users home
lua-l archive

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

2010/3/11 Sam Roberts <>:
> We want to handle some errors, but for syntax and type errors we would
> like to be able to "pass them" up to the lua
> standalone, preserving the backtrace, which often shows exactly what happened.
> This is primarly a problem for us in development, when syntax and type
> errors occur, but their location isn't indicated. The
> main advantage of error()/assert() over returning (nil,errormessage)
> is that the backtrace identifies the location.
> The loss of this info doesn't seem to be handled by John Belmonte's
> scope(), or Diego Nehab's socket.protect().
> Languages with exception handling and object hierarchies usually allow
> specification of what you want to catch,
> allowing other exceptions to pass by, and also have a rethrow/reraise
> operation in case you want to do something,
> but also pass the exception.
> I'm not sure if I can use lua's error/pcall/xpcall facilities to achieve this.
> The problem of stack trace loss is illustrated by the code below,
> output is inline in the comments.

To get a stack trace, you have to use an error handler in all your
protected calls. lua_pcall take one by default (the 4th parameter),
and from Lua you can use xpcall.

You will then have a stack trace appended every time you throw an
error (that satisfies lua_isstring). A problem you might encounter is
that if you forward an error after a pcall (with debug.traceback),
your error message will have two stack traces attached, the second one
being mostly useless since it's already included at the bottom of the
first one. I think you can overcome this by writing a custom error
handler that will detect that the error message already contains a
stack trace and will try to merge it with the result of