The extent of trust in errors and error handling

[Chris Wright via Digitalmars-d]

On Sun, 05 Feb 2017 22:23:19 -0800, Ali Çehreli wrote:

> On 02/05/2017 10:08 PM, Chris Wright wrote:
>  > How do you recommend it leave behind enough data for me to
>  > investigate the next day when I see there was a problem?
> 
> The current approach is to rely on the backtrace produced when aborting.

Which I can't log, according to you, because I don't know for certain that 
the logger is not corrupted. Which is provided by the runtime, which I 
can't trust not to be in a corrupted state. Which forces me to have at 
least two different logging systems.

At past jobs, I've used an SMTP logging appender with log4net. Wrangling 
that with a stacktrace reported only via stderr would be fun.

>  > Catching an error, logging it, and trying to move on is the obvious
> thing.
> 
> That part I can't agree with. It is not necessarily true that moving on
> will work the way we wanted. The invoice prepared for the next customer
> may have incorrect amount in it.

I've done billing. We march on, process as many invoices as possible, and 
detect problems. If there are any problems, we report them to a human for 
review instead of just submitting to the payment processor.

Besides which, you are trusting every line of code you depend on to 
appropriately distinguish between something that could impact shared state 
and something that couldn't, and to check continuously for whether shared 
state is corrupted. I'm merely trusting it not to share more state than it 
needs to.

>  > 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 heard about the Exception-Error
> distinction first in Java and I think there are other languages that
> recommend not catching Errors.

I've only been using Java professionally for seven years, so maybe that's 
before my time. The common practice today is to have `catch(Exception)` at 
a central location and to catch other exceptions as needed to make the 
compiler shut up. (Which we all hate but *has* caused me to be more 
careful about a number of things, so there's that.)