On 10/5/2014 2:51 PM, Dicebot wrote:
On Sunday, 5 October 2014 at 20:41:44 UTC, Walter Bright wrote:
On 10/5/2014 8:35 AM, Dicebot wrote:
I am fine with non-default being hard but I
want it to be still possible within legal language restricions.
D being a systems language, you can without much difficulty do whatever works
for you.
Yes but it shouldn't be in undefined behaviour domain. In other words there
needs to be a confidence that some new compiler optimization will not break the
application completely.
Relying on program state after entering an unknown state is undefined by
definition. I don't see how a language can make a statement like "it's probably ok".
Right now Throwable/Error docs heavily suggest catching it is "shoot yourself in
the foot" thing and new compiler release can possibly change its behaviour
without notice. I'd like to have a bit more specific documentation about what
can and what can't be expected. Experimental observations are that one shouldn't
rely on any cleanup code (RAII / scope(exit)) to happen but other than that it
is OK to consume Error if execution context for it (fiber in our case) gets
terminated. As D1 compiler does not change it is good enough observation for
practical means. But for D2 it would be nice to have some official
clarification.
Definitely unwinding may or may not happen from Error throws, "nothrow"
functions may throw Errors, and optimizers need not account for Errors being thrown.
Attempting to unwind the stack when an Error is thrown may cause further
corruption (if the Error was thrown because of corruption), another reason for
the language not to try to do it.
An Error is, by definition, unrecoverable.
I think this is the only important concern I have as long as power user stuff
remains possible without re-implementing whole exception system from scratch.
You can catch an Error. But what is done from there is up to you - and to do
more than just log the error, engage the backup, and exit, I cannot recommend.
To do more, use an Exception. But to throw an Exception when a logic bug has
been detected, then try and continue based on it "probably" being ok, is
something I cannot recommend and D certainly cannot guarantee anything. If the
program does anything that matters, that is.
