What is the point of nothrow?

[wjoe]

On Tuesday, 19 June 2018 at 12:26:15 UTC, Kagamin wrote:
> On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote:
>>> D allows various levels of performance and safety. Though I'd 
>>> say Errors not working in debug mode is not intended, the
>>
>> Intention matters not. By definition all program state is 
>> invalid at the point an Error was thrown. From there on it is 
>> impossible to rely on any output, too, because it could be 
>> either correct, corrupted, or completely invalid.
>
> The program is in invalid state when it hits a bug before Error 
> is thrown, this is seen as a property of a buggy algorithm, 
> Error is thrown only as a diagnostic of a bug that has happened 
> already. The state is invalid in a sense that the program 
> shouldn't continue to serve its intended purpose. Even if Error 
> was technically correctly unwound, it won't necessarily provide 
> a correct cleanup when algorithm doesn't expect an exception.
> Though in case of D situation may be not as clear as there is 
> safe code, but we just recently had a nasty memory corruption 
> bug caused by incorrect trusted code.
>

I wrote that 4 days ago. I lost some sleep over that matter and 
am long past the idea of trying to correctly clean up in this 
situation. You would know that had you read my more recent posts.

>> A core dump is created by the OS. In a format that a native 
>> debugger understands.
>
> Most of the time a stack trace is enough to diagnose the error

I'll say it again. The program must have a console(like) device 
attached. Otherwise you will not have a stack trace - or at least 
it needs to be redirected to a file but that's not very newbie 
friendly either because each shell has their own way of doing it 
and csh, for example, can't even redirect individually. I'm not 
sure about Windows. Even if possible, considering the heavy focus 
on GUI, I doubt it's considered best practices there and is a 
PITA for sure.

But maybe I missed something else and the only purpose of D is to 
make console applications for *NIX like OSs and expect users to 
be professional enough to save that stack trace before they close 
the terminal ?

And how can you be sure that this bug didn't corrupt memory of 
the druntime or anything else related to the stack trace, or even 
that it is a single bug ?

And how useful is a stack trace that shows a back trace to the 
point of the location the Error was thrown compared to a back 
trace to the location of the bug (report)?

> and provides a better UX than a core dump (especially to

Please explain. A core dump has everything a printed stack trace 
has and more and is as easy as using the debugger itself.

> newbies). I saw gdb crash trying to make sense of a debugged 
> program too. Runtime allows to override failure handlers, but 
> it's not centralized.

And what guarantee is there that the runtime doesn't crash trying 
to print a stack trace ? Could happen just as likely.