[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: is there a way to rethrow errors so that their stack trace is preserved?
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Fri, 12 Mar 2010 12:22:16 +0100
2010/3/11 Sam Roberts <vieuxtech@gmail.com>:
> 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
debug.traceback.