The extent of trust in errors and error handling

Ali Çehreli via Digitalmars-d digitalmars-d at puremagic.com
Sun Feb 5 22:23:19 PST 2017


On 02/05/2017 10:08 PM, Chris Wright wrote:
 > On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
 >> What I and many others who say Errors should not be caught are saying
 >> is, once the program is in an unexpected state, attempting to do
 >> anything further is wishful thinking.
 >
 > I've been thinking about this a bit more, and I'm curious: how do you
 > recommend that an application behave when an Error is thrown?

I don't have the answers. That's why I opened this thread. However, I 
think I know what common approaches are.

The current recommendation is that it aborts immediately before 
producing (more) incorrect results.

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

 > How do you recommend I orchestrate things
 > to minimize disruption to user activities?

That's is a hard question. If the program is interacting with the user, 
it certainly seems appropriate to communicate with them but perhaps a 
drastic abort is as good.

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

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

 > If you're telling me it's not good enough for D, you must have something
 > better in mind. What is it?

This is an interesting issue to think about. As Profile Anaysis and you 
say, this is a practical matter. We have to accept the imperfections and 
move on.

 > Or, alternatively, you know something about D that means that, when
 > something goes wrong, it effectively kills the entire application -- 
in a
 > way that doesn't happen when an Error isn't thrown, in a way that can't
 > happen in other languages.

I don't think it's possible with conventional CPUs and OSes and again.

Ali



More information about the Digitalmars-d mailing list