 |
lua-l archive |
|
|
||
|
errorlevel.lua:20: strings only, please! stack traceback: [C]: in function 'error' errorlevel.lua:14: in function 'down2' errorlevel.lua:9: in function 'down1' errorlevel.lua:4: in function 'go4it' errorlevel.lua:20: in main chunk [C]: in ?The very first line correctly identifies the line (20) in the source codeI'd like it to (and indicated when calling error with level 4).However, the traceback begins with 4 "extra" lines that'll likely confuse the person who's only seeing the client code...(while also exposing internal/implementation details I'd like to hide!).[snip< snip< snip<]
I think the information above is quite useful, but I think your point does make sense. I confess I am used to read this kind of message, but I believe it would be enough to add a signal at the proper line. [snip< snip<]
It's a nice idea to try and hilight the relevant section of a traceback. But, truth be told, any usefulness of such a mechanism only underlines the fact that the traceback shows too much in the first place (in situations like these).
While lua-l is populated with people who enjoy Lua and don't mind digging through verbose tracebacks, outside I'm often having a hard time teaching people "to read what it says". This is only made worse when tracebacks would begin with implementation details our not-so-expert users can't make heads or tails of...
The thing is, Lua does an excellent job of pointing out what's wrong in the initial error line. I believe that if error tracebacks would also honour the level parameter, this would "out of the box" greatly improve the situation for many (without any of us having to resort to trickery!).
Ashwin.