What is the point of nothrow?

[wjoe]

On Wednesday, 13 June 2018 at 03:14:33 UTC, Jonathan M Davis 
wrote:
> Most programs do not handle the case where they run out of 
> memory and cannot continue at that point. For better or worse, 
> D's GC was designed with that in mind, and it treats failed 
> allocations as an Error. In the vast majority of cases, this is 
> desirable behavior. In those cases when it isn't, alternate 
> memory allocation schemes such as malloc can be used. But

But manual memory management sucks and is a huge waste of 
everyone's time and I was hoping to get the best from both worlds 
:)

> regardless of whether the decision to treat failed memory 
> allocations as an Error was a good one or not, the fact remains 
> that as soon as an Error is thrown, you lose the ability to 
> deal with things cleanly, because full clean up is not done 
> when an Error is thrown (and can't be due to things like how 
> nothrow works). So, regardless of whether a failed memory 
> allocation is a condition that can be recovered from in 
> principle, the way that D handles GC allocations make it 
> unrecoverable in practice - at least as far as GC-allocated 
> memory is concerned.
>

Did I get that right?
You say when an error is thrown destructors, scope statements, 
etc. are not executed - if declared as nothrow because the 
exception handler mechanism stuff is missing, is that correct?
And it does execute if not declared as nothrow but can't be 
relied upon because some other  nothrow functions could have 
omitted some of those statements?

So I shoot myself in the foot with nothrow and if I don't use it 
I'm still in a world of hurt?

I understand the idea that an Error is not supposed to be caught 
but why would such a 'feature' be desirable? Where's the benefit 
if nothing can be relied upon ?

If all errors would be treated like an exception, the developer 
could decide whether it is an error which needs to terminate 
right away or be able to handle the issue and continue or 
gracefully shutdown. Could even set a break point or force a core 
dump right there.
If the exception would be ignored the program will crash 
regardless but at least there would be a stack trace that I could 
rely upon instead of this unreliable and possibly corrupt state 
which is good for nothing.

This concept is a bit like color everyone with the same brush or 
one shoe fits all. Where in reality it depends on the 
circumstances whether it is an error or an exception.
But maybe I feel that way because currently there's a bit of a 
blur regarding what's defined as Errors and Exceptions.

Anyways I took a lot from your awesome explanations so far. 
Thanks a ton!