Program logic bugs vs input/environmental errors

[Dicebot via Digitalmars-d]

On Sunday, 5 October 2014 at 23:01:48 UTC, Walter Bright wrote:
> 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".

It is only in undefined state because language handles Errors 
that way. At the point of throwing the Error state was perfectly 
defined and 100% recoverable. This is the typical case for 
assertion failure in contract - it detects some program flaw like 
inability to handle specific data combination from other process 
but it does not mean memory is corrupted or program is inherently 
broken. Just killing the fiber and continuing with other requests 
(which don't trigger that unexpected code path) is absolutely 
fine unless compiler kicks in and optimizes something away in 
surprising fashion.

If destructors are ignored those must be always ignored and 
defined in spec. Same for scope(exit) or any similar affected 
feature. Currently it may or may not attempt cleanup and that is 
the problem when trying to circumvent the semantics.

>> 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.

Killing whole process is unacceptable in many cases, it will 
effectively shut down the whole service if faulty request happens 
at least one in a few seconds.

> 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.

Assertions / contracts use Error. Do you think it is a better 
approach to prohibit using `assert` and throw custom exceptions 
from contracts?