Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 13:13:01 UTC, ketmar wrote:
> this still nullifies the sense of Error/Exception differences. 
> not all errors are recoverable, even in @safe code.
>
> ...
>
> using wrappers and carefully checking preconditions looks 
> better to me. after all, if programmer failed to check some 
> preconditions, the worst thing to do is trying to hide that by 
> masking errors. bombing out is *way* better, i believe, 'cause 
> it forcing programmer to really fix the bugs instead of 
> creating hackish workarounds.

I don't think this is a workaround, or that it goes against the 
purpose of Errors.

The goal would still be to bomb out, cancel whatever you were 
doing, print a big red error message to the coder / user, and 
exit.

A program that catches an Error would not try to use the data 
that broke a contract; in fact, the program would not have access 
to the invalid data, since it would be thrown away. It's natural 
progression would be to log the error, and quit whatever it was 
doing.

The point is, if the program needs to free system resources 
before shutting down, it could do so; or if the program is a 
server or a multi-threaded app dealing with multiple clients at 
the same time, those clients would not be affected by a crash 
unrelated to their data.