 |
lua-l archive |
|
|
||
|
On 29/10/2014 14.57, Michal Kolodziejczyk wrote:
I think (read: am afraid) that many tools depend on exact error message format. OTOH, if I used lua, I would want to be able to parse error messages independent on user locale, i.e. don't want user's locale setting to mess with error messages of the interpreter. The solution(?) would be to use "error objects" - each error message (object/structure) would have its unique errorId, and optional parameters. Then render those messages at the highest possible level, possibly using default lua renderer and a map of errorId to errorMessages. But it seems like a lot of work.
That would be a sensible (if possibly costly) solution. I encountered more than once, while designing user-oriented DSLs, the need to catch a Lua error and display meaningful information about it. Catching the error is easy (just use pcall), decoding and/or re-encoding the error message in a user-suitable way (even in English!) is not. I do not think that parsing error messages, relying on exact wording, would be a good idea.
That's why some time ago I proposed the (very partial) low cost 'solution' of prepending an unique code to error messages, e.g.:
a.lua:23: [e123] attempting to index a nil value (global 'x')It would be easy to identify the error type (file and line are already there), though any extra information (such as 'x') would be lost. Efficient but sadly incomplete. I am sure the Lua developers can thing of an efficient *and* effective way :-)
For my own code I just use error() statements and catch them with pcall. However, this does not solve the problem of reporting errors inside user chunks in a user-friendly (and DSL-related) way.
-- Enrico