Bug 14885 – ideas for prettier and more useful backtraces

Some trivial to implement ideas to make backtraces more useful. Turn backtraces upside down. Often one get's a long backtrace on the console and has to scroll up skipping all the internal/framework frames to find the actual function that threw an exception and see the error message. It would be a lot easier if the backtrace was from top to bottom with the message below that. ---- std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2013): Unexpected end of input when converting from type string to type int ---------------- ./bug(pure @safe int std.conv.toImpl!(int, immutable(char)[]).toImpl(immutable(char)[])+0x26) [0x42bdae] ./bug(pure @safe int std.conv.to!(int).to!(immutable(char)[]).to(immutable(char)[])+0x20) [0x42ba88] ./bug(_Dmain+0x1a) [0x42ba62] ./bug(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x42de27] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x42dd82] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x2b) [0x42dde3] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x42dd82] ./bug(_d_run_main+0x1d2) [0x42dd02] ./bug(main+0x12) [0x42bec2] /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f0f30c17fe0] ---- vs. ---- /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f0f30c17fe0] ./bug(main+0x12) [0x42bec2] ./bug(_d_run_main+0x1d2) [0x42dd02] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x42dd82] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x2b) [0x42dde3] ./bug(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x42dd82] ./bug(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x42de27] ./bug(_Dmain+0x1a) [0x42ba62] ./bug(pure @safe int std.conv.to!(int).to!(immutable(char)[]).to(immutable(char)[])+0x20) [0x42ba88] ./bug(pure @safe int std.conv.toImpl!(int, immutable(char)[]).toImpl(immutable(char)[])+0x26) [0x42bdae] ---------------- std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2013): Unexpected end of input when converting from type string to type int ----

Many editors understand the /usr/include/dmd/phobos/std/conv.d:2013 syntax so using that allows to faster go to the code that threw an exception. ---- std.conv.ConvException@/usr/include/dmd/phobos/std/conv.d(2013): Unexpected end of input when converting from type string to type int ---- vs. ---- /usr/include/dmd/phobos/std/conv.d:2013: Unexpected end of input when converting from type string to type int (std.conv.ConvException) ----

Colored output for unhandled exceptions would also help to highlight the important parts (the message, the location, and the type).

And of course we need to parse ELF debug info to print line numbers and nicer symbol names, see issue 11870.

I agree, that would be nice. I also think the name of the function is actually mostly just noise; they are too long to read in most cases. I'd kinda prefer it just give the last part of the name without the arguments (so just plain `to` instead of `pure @safe int std.conv.to!(int).to!(immutable(char)[]).to(immutable(char)[])`... maybe with template args, but they get ridiculously long too, but just the name followed by a way to get more info. An external tool (which we could provide) could then get more info as requested from the backtrace line, like the full function name. (Even with line numbers, listing the address is probably useful for more info...)

(In reply to Martin Nowak from comment #0) > Turn backtraces upside down. > Often one get's a long backtrace on the console and has to scroll up > skipping all the internal/framework frames to find the actual function that > threw an exception and see the error message. > > It would be a lot easier if the backtrace was from top to bottom with the > message below that. That would go against existing conventions pretty much anywhere. Debuggers (GDB, Visual Studio), as most other programming languages (Java, C#, Ruby) show stack traces with the most recent call first. Python is an exception, which explains why I always get confused when reading Python stack traces.

(In reply to Martin Nowak from comment #1) > Many editors understand the /usr/include/dmd/phobos/std/conv.d:2013 syntax > so using that allows to faster go to the code that threw an exception. And the terminal I'm using (iTerm)

(In reply to Adam D. Ruppe from comment #4) > An external tool (which we could provide) could then get more info as > requested from the backtrace line, like the full function name. (Even with > line numbers, listing the address is probably useful for more info...) I would prefer to have an option to print the full output. Because some editors use HTML as the output. Then it's possible to render a more advanced output, with some UI to toggle the visibility of some parts of the output.

(In reply to Jacob Carlborg from comment #7) > I would prefer to have an option to print the full output. Because some > editors use HTML as the output. Then it's possible to render a more advanced > output, with some UI to toggle the visibility of some parts of the output. Perhaps that switch should just print errors in a machine-readable format (XML/JSON) then.

One idea would be to use an abbreviation scheme for template parameters, similar to how we want to abbreviate the mangling. https://issues.dlang.org/show_bug.cgi?id=15831#c13 Another pragmatic approach is to just show the FQN, but no template parameters. Might lack some important information, but with the upper stacktrace parts leading to the template, things should be clear most of the time.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17308 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB