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

[Josphe Brigmo]

On Friday, 14 September 2018 at 15:52:20 UTC, Neia Neutuladh 
wrote:
> 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.


It is because you are throwing inside your code. When the throw 
is from the library, it gives something like this:


std.file.FileException at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153): test.txt: Access is denied.
----------------
0x000B043A
0x000B0356
0x000A2899
0x000A2CC0
0x000A2CC0
0x000A2CC0
0x000A2CC0
0x000A11EF
0x000BD0EF
0x000BD06D
0x000BCF01
0x000B2EA8
0x00113B5E
0x00113A51
0x001138FD
0x00113BC8
0x76148744 in BaseThreadInitThunk
0x7795582D in RtlGetAppContainerNamedObjectPath
0x779557FD in RtlGetAppContainerNamedObjectPath


Where the error is from file. In visual D this always breaks in 
to the library(which is very annoying but it does show a full 
stack trace and lets one view the frame).
I could wrap my entire program in a try catch and maybe that will 
offer some new information, but It seems pointless to do that. 
The stack should be displayed and much of the nonsense 
removed(like the 20 lines of pointers which is useless to me(they 
will be invalid when the program exists so why show them?).