lua-users home
lua-l archive

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


Hola Enrique,

On Fri, 20 Sep 2013 11:31:34 +0200
Enrique Garcia Cota <kikito@gmail.com> wrote:
> The problem is as follows: in some situations (sandboxes or testing libs,
> for example), it is useful to catch an error, do some operations and then
> raise it again. When doing so, it is very useful to provide the traceback
> of the original error.

There are many things you may want to do upon a Lua error, in addition to capturing the traceback. The safest solution is probably to handle those cases in C, and bypass Lua's stack to pass them up to your topmost calling code, since some errors may limit what the Lua VM is still able to do [1] (generated from [2]).

> On the other hand, if msg is something different, like a table or a number,
> it must be severely transformed if we want to conserve the traceback.

By the time you intercept a native Lua error it's already converted to a string by the Lua VM, so you don't need to handle another data type... unless client/user Lua script throws its own errors in a different format. In that case I agree that determining the error format is problematic, since the last place you want to start guessing is inside an error handler.

If all you want is to extract a traceback, Lua's current architecture works just fine.

> That's all. Thank you so much for Lua, it's great.

It is :)

Saludos,

-- p


[1] http://www.laufenberg.ch/lua/dump.log
[2] http://www.laufenberg.ch/lua/err_scan.lua