www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - call traceback is indecipherable garbage

reply forkit <forkit gmail.com> writes:
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
Jan 25 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 26/01/2022 3:20 PM, forkit wrote:

 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


That's your call stack (addresses).

It doesn't have the function name/module because you haven't compiled it in.

If you don't want it, catch any exceptions that can be thrown.
Jan 25 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 02:22:53 UTC, rikki cattermole 
wrote:

 That's your call stack (addresses).

 It doesn't have the function name/module because you haven't 
 compiled it in.

 If you don't want it, catch any exceptions that can be thrown.


I'd rather have more options available to me:

e.g:

dmd -tracebackPrint=no myfile.d
Jan 25 2022
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/25/22 9:27 PM, forkit wrote:

 On Wednesday, 26 January 2022 at 02:22:53 UTC, rikki cattermole wrote:

 That's your call stack (addresses).

 It doesn't have the function name/module because you haven't compiled 
 it in.

 If you don't want it, catch any exceptions that can be thrown.


 
 I'd rather have more options available to me:
 
 e.g:
 
 dmd -tracebackPrint=no myfile.d
 


Catching an exception and handling it directly is exactly how you do 
this. Dmd can't have all the options to write code for you.

-Steve
Jan 25 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 02:31:25 UTC, Steven 
Schveighoffer wrote:

 Catching an exception and handling it directly is exactly how 
 you do this. Dmd can't have all the options to write code for 
 you.

 -Steve


of course opening a non-existent file was an arbitrary example 
(and should be ignored).

The garbage being output is really the focus of my question.

At the very least, it should be removed in -release I think.

I'd be interested in knowing how many (and who) actually make use 
of the output under the ------ part.
Jan 25 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/25/22 9:40 PM, forkit wrote:

 On Wednesday, 26 January 2022 at 02:31:25 UTC, Steven Schveighoffer wrote:

 Catching an exception and handling it directly is exactly how you do 
 this. Dmd can't have all the options to write code for you.


 
 of course opening a non-existent file was an arbitrary example (and 
 should be ignored).
 
 The garbage being output is really the focus of my question.
 
 At the very least, it should be removed in -release I think.
 
 I'd be interested in knowing how many (and who) actually make use of the 
 output under the ------ part.


If you compile with debug symbols, you get an actual stack trace. (even 
in -release mode)

Now, with proper spelunking tools, I'm sure you could figure out all the 
information from those addresses, but the runtime is printing everything 
it can about the stack trace, which isn't much.

-Steve
Jan 25 2022
prev sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 02:27:52 UTC, forkit wrote:

 I'd rather have more options available to me:

 e.g:

 dmd -tracebackPrint=no myfile.d


or better yet, just make an addition to the already existing 
-debug=(option)

dmd -debug=stracktrace myfile.d

after all, a dump of stack trace is for 'debugging', and not 
something that one should see in -release.

How hard would that be I wonder?

btw. I just noticed a big difference in what ldc2 dumps, compared 
to what dmd dumps??
Jan 25 2022
prev sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 02:22:53 UTC, rikki cattermole 
wrote:

 That's your call stack (addresses).

 It doesn't have the function name/module because you haven't 
 compiled it in.

 If you don't want it, catch any exceptions that can be thrown.


Why could argue, that it's already been caught ;-)
Jan 25 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 26, 2022 at 02:20:17AM +0000, forkit via Digitalmars-d wrote:
[...]

 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


Did you compile with debugging symbols, i.e., with -g?

For example, given this code:

	void can() { throw new Exception("buahaha"); }
	void if_you() { can(); }
	void catch_me() { if_you(); }
	void can_you() { catch_me(); }
	void main() {
		can_you();
	}

Running with `dmd -run test.d` produces:

	object.Exception /tmp/test.d(1): buahaha
	----------------
	??:? void test.can() [0x55c95255673b]
	??:? void test.if_you() [0x55c952556748]
	??:? void test.catch_me() [0x55c952556754]
	??:? void test.can_you() [0x55c952556760]
	??:? _Dmain [0x55c95255676c]

Not bad, but not very helpful. If there are some inner functions you
might not get the function names either.

Running with `dmd -g -run test.d` produces:

	object.Exception /tmp/test.d(1): buahaha
	----------------
	/tmp/test.d:1 void test.can() [0x55cff3e3773b]
	/tmp/test.d:2 void test.if_you() [0x55cff3e37748]
	/tmp/test.d:3 void test.catch_me() [0x55cff3e37754]
	/tmp/test.d:4 void test.can_you() [0x55cff3e37760]
	/tmp/test.d:6 _Dmain [0x55cff3e3776c]

Voila! Line numbers and source filenames!


T

-- 
Gone Chopin. Bach in a minuet.
Jan 25 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 03:33:31 UTC, H. S. Teoh wrote:

 Running with `dmd -g -run test.d` produces:

 ....

 T


Interesting. Thanks for mentioning that -g option.

Still, it makes complete sense to me, that a stack trace dump is 
'debugging material', and that -release should print only the 
exeption, and nothing else.

Surely I'm not the only one who has come to that conclusion :-(
Jan 25 2022
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 26, 2022 at 03:51:55AM +0000, forkit via Digitalmars-d wrote:
[...]

 Still, it makes complete sense to me, that a stack trace dump is
 'debugging material', and that -release should print only the
 exeption, and nothing else.


It's easy, just wrap your main() in a try-catch block:

	int main() {
		try {
			// ... rest of code goes here
			return 0;
		} catch(Exception e) {
			writeln("Error: %s", e.msg);
			return 1;
		}
	}


T

-- 
Your inconsistency is the only consistent thing about you! -- KD
Jan 25 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 04:25:47 UTC, H. S. Teoh wrote:

 It's easy, just wrap your main() in a try-catch block:

 	int main() {
 		try {
 			// ... rest of code goes here
 			return 0;
 		} catch(Exception e) {
 			writeln("Error: %s", e.msg);
 			return 1;
 		}
 	}


 T


great!

.. now my 2 little lines of code, has turned into all this 
peripheral nonesense, just to avoid displaying the useless stack 
dump.

;-(

// --
module test;
import std;

int main()
{
     try
     {
         auto f = File("d://tewxt.txt").byLine;
         f.take(1).each!writeln;

         return 0;
     }
     catch(Exception e)
     {
         writeln("Error: %s", e.msg);
         return 1;
     }
}
// ---
Jan 25 2022
next sibling parent frame <frame86 live.com> writes:
On Wednesday, 26 January 2022 at 05:17:48 UTC, forkit wrote:


 .. now my 2 little lines of code, has turned into all this 
 peripheral nonesense, just to avoid displaying the useless 
 stack dump.


There is currently an open bug which prevents a stack trace - 
just link a DLL statically with an initialized runtime in it :D
https://issues.dlang.org/show_bug.cgi?id=22181
Jan 26 2022
prev sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Wednesday, 26 January 2022 at 05:17:48 UTC, forkit wrote:

 On Wednesday, 26 January 2022 at 04:25:47 UTC, H. S. Teoh wrote:

 It's easy, just wrap your main() in a try-catch block:

 [...]


 great!

 .. now my 2 little lines of code, has turned into all this 
 peripheral nonesense, just to avoid displaying the useless 
 stack dump.

 ;-(

 [...]


you could implement a custom _d_print_throwable:

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

This is called on uncaught exceptions, on assert failure and 
other internal fatal errors that exit the program. So make sure 
that the handler itself doesn't crash!

Example: https://run.dlang.io/is/DBhyZW

```d
void main()
{
     throw new Exception("uncaught!");
}

extern (C) void _d_print_throwable(Throwable t) nothrow
{
     import core.stdc.stdio;

     fprintf(stderr, "%.*s", cast(int)t.msg.length, t.msg.ptr);
}
```
Jan 26 2022
prev sibling parent Dennis <dkorpel gmail.com> writes:
On Wednesday, 26 January 2022 at 03:51:55 UTC, forkit wrote:

 Still, it makes complete sense to me, that a stack trace dump 
 is 'debugging material', and that -release should print only 
 the exeption, and nothing else.

 Surely I'm not the only one who has come to that conclusion :-(


https://forum.dlang.org/post/m09gue$38e$1 digitalmars.com

I wouldn't be against only printing the Exception message by 
default either, but others consider letting an Exception escape 
`main` a bug, and think you should explicitly catch Exceptions 
that you expect might be thrown.
Jan 26 2022
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/25/22 9:20 PM, 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
 


Regardless of the "correct" way to deal with this, I agree with you that 
printing code addresses is not helpful. I'm assuming this is Windows? Is 
there nothing better that can be done?

-Steve
Jan 25 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 26 January 2022 at 03:45:01 UTC, Steven 
Schveighoffer wrote:

 Regardless of the "correct" way to deal with this, I agree with 
 you that printing code addresses is not helpful. I'm assuming 
 this is Windows? Is there nothing better that can be done?

 -Steve


You mean stop using Windows?
Jan 25 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/25/22 10:56 PM, forkit wrote:

 On Wednesday, 26 January 2022 at 03:45:01 UTC, Steven Schveighoffer wrote:

 Regardless of the "correct" way to deal with this, I agree with you 
 that printing code addresses is not helpful. I'm assuming this is 
 Windows? Is there nothing better that can be done?


 
 You mean stop using Windows?


No I mean, on Windows, is there no better thing to print out for a stack 
frame other than the address? Not a question aimed at you ;)

If I don't include debug info for Mac (even if I strip the executable), 
I still get function names, but not file/line info.

I'm pretty sure Windows isn't the only OS that does this by default, but 
I can't remember all the different OSes I've tried D on.

-Steve
Jan 25 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Wednesday, 26 January 2022 at 02:20:17 UTC, forkit wrote:

 has anyone ever considered getting rid of the indecipherable


`Forum oriented programming`.
Jan 25 2022
prev sibling next sibling parent reply forkit <forkit gmail.com> writes:
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.



 Jan 26 2022



 next sibling parent  rikki cattermole <rikki cattermole.co.nz>  writes:


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



 Jan 26 2022



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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.



 Jan 26 2022



 next sibling parent  forkit <forkit gmail.com>  writes:


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 */
     }
}



 Jan 26 2022



prev sibling next sibling parent reply forkit <forkit gmail.com>  writes:


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 ;-)



 Jan 30 2022



  parent  max haughton <maxhaton gmail.com>  writes:


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



 Jan 30 2022



prev sibling  parent reply kinke <noone nowhere.com>  writes:


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.


One can easily disable any exception traces via 
https://dlang.org/phobos/core_runtime.html#.Runtime.traceHandler:
```
void main() {
     import core.runtime : Runtime;
     Runtime.traceHandler = null;

     throw new Exception("oops");
}
```

[That won't just avoid the output, but also makes EH faster.]

One can also set a custom function, e.g., to make tracing depend 
on some environment variable, reusing 
https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler.



 Feb 04 2022



  parent reply forkit <forkit gmail.com>  writes:


On Friday, 4 February 2022 at 19:04:24 UTC, kinke wrote:

 One can easily disable any exception traces via 
 https://dlang.org/phobos/core_runtime.html#.Runtime.traceHandler:
 ```
 void main() {
     import core.runtime : Runtime;
     Runtime.traceHandler = null;

     throw new Exception("oops");
 }
 ```

 [That won't just avoid the output, but also makes EH faster.]

 One can also set a custom function, e.g., to make tracing 
 depend on some environment variable, reusing 
 https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler.


Thanks. Very useful info :-)

Although, I almost always need to compile with '-g' in order for 
the strace to be of any practical use.

So I will likely end up incorporating above, into this:

debug
     {
         import core.runtime : Runtime;
         Runtime.traceHandler = null;
     }



 Feb 04 2022



  parent reply forkit <forkit gmail.com>  writes:


On Friday, 4 February 2022 at 22:47:18 UTC, forkit wrote:

 Thanks. Very useful info :-)

 Although, I almost always need to compile with '-g' in order 
 for the strace to be of any practical use.

 So I will likely end up incorporating above, into this:

 debug
     {
         import core.runtime : Runtime;
         Runtime.traceHandler = null;
     }


oops. of course I meant:

!debug
     {
         import core.runtime : Runtime;
         Runtime.traceHandler = null;
     }

btw. how do I do that exactly (ie. !debug)



 Feb 04 2022



 next sibling parent  forkit <forkit gmail.com>  writes:


On Friday, 4 February 2022 at 22:50:12 UTC, forkit wrote:

 btw. how do I do that exactly (ie. !debug)


this seems messy:

     debug
     {

     }
     else
     {
         import core.runtime : Runtime;
         Runtime.traceHandler = null;
     }


!debug would be much nicer.



 Feb 04 2022



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Feb 04, 2022 at 10:50:12PM +0000, forkit via Digitalmars-d wrote:
[...]

 btw. how do I do that exactly (ie. !debug)


	version(debug) {} else {
		... // non-debug stuff goes here
	}

If you don't like that, e.g. if you have to do this many times in your
code, you could do something like this:

	// Do this once
	version(debug) enum isDebug = true;
	else enum isDebug = false;

	...

	// Do this whenever you need
	static if (!isDebug) {
		... // non-debug stuff here
	}


T

-- 
Guns don't kill people. Bullets do.



 Feb 04 2022



prev sibling  parent reply FeepingCreature <feepingcreature gmail.com>  writes:


On Wednesday, 26 January 2022 at 21:02:09 UTC, 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.


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."



 Jan 31 2022



  parent reply forkit <forkit gmail.com>  writes:


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


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



 Jan 31 2022



 next sibling parent reply FeepingCreature <feepingcreature gmail.com>  writes:


On Monday, 31 January 2022 at 09:42:27 UTC, forkit wrote:

 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


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


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.

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.

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.



 Jan 31 2022



  parent reply forkit <forkit gmail.com>  writes:


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.



 Jan 31 2022



  parent  Siarhei Siamashka <siarhei.siamashka gmail.com>  writes:


On Monday, 31 January 2022 at 20:43:21 UTC, forkit wrote:

 On Monday, 31 January 2022 at 15:57:44 UTC, FeepingCreature 
 wrote:


 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.


End-users are not supposed to decipher this nonsense. They are 
supposed to paste it in a bugreport reported against your 
application, so that you can decipher it. Some applications even 
have built-in pop-up dialogs, suggesting the user to send a crash 
report to developers with just a single button click.



 Feb 01 2022



prev sibling  parent  bauss <jj_1337 live.dk>  writes:


On Monday, 31 January 2022 at 09:42:27 UTC, forkit wrote:

 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


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


I would much rather that you disable stacktraces rather than 
enables them.

I have systems running for months without being able to just 
rerun on the fly when it fails.

Without a stacktrace that would fail and I most definitely 
wouldn't remember to enable that for every program I run.



 Feb 01 2022



prev sibling  parent  deadalnix <deadalnix gmail.com>  writes:


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.



 Jan 27 2022