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!
