On 27/01/2022 10:02 AM, forkit wrote:
> On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
>>
> btw. I really like how Rust does it:
> 
> just set an environment variable (set RUST_BACKTRACE=1)
> 
> then run your program, and it will dump the backtrace, when you run your program.

Here is where that would be implemented (I think anyway).

https://github.com/dlang/druntime/blob/33511e263134530a5994a775b03a061ea3f1aa34/src/rt/dmain2.d#L530

On Wed, Jan 26, 2022 at 09:02:09PM +0000, forkit via Digitalmars-d wrote:
> On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
> > 
> btw. I really like how Rust does it:
> 
> just set an environment variable (set RUST_BACKTRACE=1)
> 
> then run your program, and it will dump the backtrace, when you run your program.
[...]

File this as an enhancement request, it might be worth implementing.


T

-- 
Doubt is a self-fulfilling prophecy.

On Wednesday, 26 January 2022 at 21:11:42 UTC, H. S. Teoh wrote:
> On Wed, Jan 26, 2022 at 09:02:09PM +0000, forkit via Digitalmars-d wrote:
>> On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
>> > 
>> btw. I really like how Rust does it:
>> 
>> just set an environment variable (set RUST_BACKTRACE=1)
>> 
>> then run your program, and it will dump the backtrace, when you run your program.
> [...]
>
> File this as an enhancement request, it might be worth implementing.
>
>
> T

will look into this. In the meantime, I can just comment out 2 lines, and problem goes away ;-)

try
{
    /* sink("\n----------------"); */ /* line 2463 object.d */
    foreach (t; info)
    {
        /* sink("\n"); sink(t); */ /* line 2466 object.d */
    }
}

On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
> has anyone ever considered getting rid of the indecipherable garbage after ----
> (or having some compile time option to not output it?)
>
> I don't want to see it.
>
> I sure don't want my end-users to see it either.
>
>
> / --
>
> module test;
> import std;
> void main()
> {
>     File f = File("nosuchfile");
> }
>
> // --
>
> Exit code is: 1
>
> std.exception.ErrnoException@std\stdio.d(545): Cannot open file `nosuchfile' in mode `rb' (No such file or directory)
> ----------------
> 0x000000013FB5F836
> 0x000000013FB53423
> 0x000000013FB51269
> 0x000000013FB51057
> 0x000000013FB5ECB3
> 0x000000013FB5EB2F
> 0x000000013FB5EC1B
> 0x000000013FB5EB2F
> 0x000000013FB5EA56
> 0x000000013FB53171
> 0x000000013FB51094
> 0x000000013FBD2F68
> 0x0000000076F9556D in BaseThreadInitThunk
> 0x00000000771F372D in RtlUserThreadStart

You might want to share how you are compiling this. The detail will change how much the runtime can tell you.

Make sure you compile in the debug mode. If you don't use the compiler itself to link, make sure you pass the `-export-dynamic` flag to the linker.

On Wednesday, 26 January 2022 at 21:11:42 UTC, H. S. Teoh wrote:
> On Wed, Jan 26, 2022 at 09:02:09PM +0000, forkit via Digitalmars-d wrote:
>> On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
>> > 
>> btw. I really like how Rust does it:
>> 
>> just set an environment variable (set RUST_BACKTRACE=1)
>> 
>> then run your program, and it will dump the backtrace, when you run your program.
> [...]
>
> File this as an enhancement request, it might be worth implementing.
>
>
> T


https://github.com/dlang/DIPs/pull/222

tested and working fine ;-)

On Monday, 31 January 2022 at 00:56:38 UTC, forkit wrote:
> On Wednesday, 26 January 2022 at 21:11:42 UTC, H. S. Teoh wrote:
>> On Wed, Jan 26, 2022 at 09:02:09PM +0000, forkit via Digitalmars-d wrote:
>>> On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:
>>> > 
>>> btw. I really like how Rust does it:
>>> 
>>> just set an environment variable (set RUST_BACKTRACE=1)
>>> 
>>> then run your program, and it will dump the backtrace, when you run your program.
>> [...]
>>
>> File this as an enhancement request, it might be worth implementing.
>>
>>
>> T
>
>
> https://github.com/dlang/DIPs/pull/222
>
> tested and working fine ;-)

This should be a druntime PR

On Monday, 31 January 2022 at 08:56:17 UTC, FeepingCreature wrote:
>
> I think this is not a good idea. This sounds like the sort of environment variable that you usually, when it matters, want to *have set* a while ago, rather than set that moment. It's just one more "gotcha that you just need to know to work with the language."

so that 'gotcha' is easily solved.

when an error is printed, on the next line it could say this:

=========================

std.exception.ErrnoException@std\stdio.d(545): Cannot open file `nosuchfile' in mode `rb' (No such file or directory)

------------------------------------------------------------------
To see stack backtrace, set evironment variable: DLANG_BACKTRACE=1


=============================================

On Monday, 31 January 2022 at 15:57:44 UTC, FeepingCreature wrote:
>
> I think you're coming at this with the model that the user can just re-run the program that's thrown the error. But consider long-running services deployed in an enterprise context. In that situation, if an error occurs, there might be quite a long time until you get to see it again - you can't just rerun the program, because the "program" is actually a docker container processing live user data, and you can't just call up your users and tell them "do that thing again" because it may have been many hours ago. In that situation - well, in that situation, usually you will have long ago set that environment variable by default in your reused deployment code. But it's still going to be annoying to the people trying to debug what went wrong there.

A running program is unaffected.

It would have to be recompiled before this change is adopted.

This provides the opportunity to set that environment variable, 'if needed'.

> On the other hand, with a console app usually the developer will have encountered errors plenty of times during development. So they'll probably have wrapped main with a `catch (Throwable) { writeln(Throwable.msg); exit(1); }` or something.

Nice. I hope the developer properly considered this during the development process ;-)


> I think it's better by default to give more info rather than less. You can always ignore stuff you don't care about; you can't anti-ignore stuff that was never printed.

Knowing what frames are on the call stack when an exception is caught by the runtime is a 'debugging aid'. I do not see the case for having it printed by default, resulting in end-users trying to decipher it's nonsense.