https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
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)
----

--

https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
Colored output for unhandled exceptions would also help to highlight the important parts (the message, the location, and the type).

--

https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
And of course we need to parse ELF debug info to print line numbers and nicer symbol names, see issue 11870.

--

https://issues.dlang.org/show_bug.cgi?id=14885

Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator@gmail.com

--- Comment #4 from Adam D. Ruppe <destructionator@gmail.com> ---
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...)

--

https://issues.dlang.org/show_bug.cgi?id=14885

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=14885

Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com

--- Comment #6 from Jacob Carlborg <doob@me.com> ---
(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)

--

https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #7 from Jacob Carlborg <doob@me.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #8 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=14885

--- Comment #9 from Martin Nowak <code@dawg.eu> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=14885

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--