The extent of trust in errors and error handling

[Caspar Kielwein via Digitalmars-d]

On Monday, 6 February 2017 at 17:40:50 UTC, Chris Wright wrote:
>> It works for every other programming language I've encountered.
>> 
>> This issue is language agnostic. It works in D as well but at 
>> the same level of
>> correctness and unknowns.
>
> I haven't heard anyone complaining about this elsewhere. Have 
> you?
>
> What I've heard instead is that it's a bug if state 
> unintentionally leaks between calls and it's undesirable to 
> have implicitly shared state. Not sharing state unnecessarily 
> means you don't have to put forth a ton of effort trying to 
> detect corrupted shared state in order to throw an Error to 
> signal that your library is unsafe to use.

I absolutely agree with Walter and Ali, that there are 
applications where on Error anything but termination of the 
process is unacceptable. This really is independent of the 
language used.

My work is in sensors for automation of heavy mining equipment 
and the software I write is used by the automation systems of our 
customers.

When our system detects an internal error I cannot guarantee for 
any of its outputs. Erroneous outputs can easily cost millions of 
dollars in machine damage, or in the worst case even human lives. 
(Usually there are redundant systems to mitigate that risk)
Termination of our system is automatically detected by automation 
systems within the specified latencies and is generally 
considered to be annoying but acceptable. Nonsense outputs 
because of errors in our system are never acceptable!

We try to find the cause of errors by logging the raw data from 
our sensors and feeding them to a clone of the system which has 
more debugging and logging enabled. Yes we usually don't even get 
a stack trace from the original crash.

I have definitely seen asserts violated because of buffer 
overflows in completely unrelated modules. Not sharing state 
unnecessarily, while certainly being good engineering practice is 
not enough.