Why the hell do exceptions give error in the library rather than the user code?

[Neia Neutuladh]

On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
> std.file.FileException at 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 at 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.