Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

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.