The extent of trust in errors and error handling

[Chris Wright via Digitalmars-d]

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? How do you 
recommend it leave behind enough data for me to investigate the next day 
when I see there was a problem? How do you recommend I orchestrate things 
to minimize disruption to user activities?

Catching an error, logging it, and trying to move on is the obvious thing. 
It works for every other programming language I've encountered.

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

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.