call traceback is indecipherable garbage

[forkit]

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.