On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is pointing
to code in a library which tells me absolutely nothing about
where the error occurs in the in the user code(which is what
matters).
It's what matters when the exception is caused by a bug in user
code. It's what matters when the exception is caused by something
environmental and the operation was a narrow, focused operation
directed by user code.
If you have a bug caused by something in the depths of a complex
library, the full stacktrace matters.
Surely the call stack can be unrolled to find code that exists
in the user code? Or at least display several lines like a
trace stack.
They do, I thought? Let me test quickly:
---
void doThrow()
{
throw new Exception("here!");
}
void main()
{
try
doThrow;
catch (Exception e)
writeln(e);
}
---
That prints something like:
object.Exception@scratch.d(7): here!
----------------
scratch.d:7 void scratch.doThrow() [0x9d8acd53]
scratch.d:14 _Dmain [0x9d8acd68]
That's a stacktrace.
And if I don't catch the exception, the runtime still gives me a
stacktrace.
You do need to include debug symbols to get filenames and line
numbers; just compile with -g.
