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.
