Stack traces in the Shell and Lua REPL
SquidDev opened this issue ยท 1 comments
When a program or input to the Lua REPL errors, we should display the stack trace that caused this error, along with the message itself:
This is something mbs, OC and "actual proper" Lua have had for a while, and it helps a lot in tracking down the issue.
Just a couple of thoughts on the implementation:
-
Stack traces should be configurable via the
shell.stack_trace
andlua.stack_trace
settings. Whether these should be on by default is open to debate (though the answer is yes :p). -
I think the best approach to gathering the stack trace would be to run the function within a coroutine, and if it crashes use
debug.traceback
on the coroutine. While this does mean the feature will not run without thedebug
API, it avoids the problem of stack overflows and having to trim the traceback.
Given coroutines are effectively free nowadays anyway, it shouldn't be a performance concern. -
We may need to trim the stack trace in order to fit it on the screen - Lua does this by dropping out the middle lines.
-
The shell should probably only print stack traces when the error message is a string, and matches the pattern
^.+:%d+:
- we don't want to print stack traces on programs which useerror()
orerror(.., 0)
to exit.
There's also a couple of things worth discussing:
-
There's an argument that reversing the stack trace (message at the bottom, and then lines going from bottom to top) is more logical than Lua's default one - this is what Python does:
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 5, in foo File "<stdin>", line 5, in foo File "<stdin>", line 5, in foo File "<stdin>", line 3, in foo Exception: Oh No
I kinda like it, but do worry it may end up confusing people. Thoughts?
-
How can we ensure that stack traces are useful, rather than just contributing noise?
-
How do we handle things like the
parallel
API, where the stack trace is not available (as it occurred on a separate coroutine)?