On 31.05.2012 13:06, deadalnix wrote:
Le 31/05/2012 04:17, Walter Bright a écrit :
On 5/30/2012 8:05 AM, Steven Schveighoffer wrote:
I'd classify errors/exceptions into three categories:
1. corruption/segfault -- not recoverable under any reasonable
circumstances.
Special cases exist (such as a custom paging mechanism).
2. program invariant errors (i.e. assert errors) -- Recovery is not
defined by
the runtime, so you must do it manually. Any decision the runtime
makes will be
arbitrary, and could be wrong.
3. try/catch exceptions -- these are planned for and *expected* to
occur because
the program cannot control it's environment. e.g. EOF when none was
expected.
A recoverable exception is NOT a logic bug in your program, which is why
it is recoverable.
If there is recovery possible from a particular assert error, then you
are using asserts incorrectly. Assert errors occur because your program
has entered an unanticipated, invalid state. There's no such thing as
knowing how to put it back into a valid state, because you don't know
where it went wrong and how much is corrupted, etc.
A failure in database component should prevent me from close a network
connection properly in an unrelated part of the program.
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exactly. + The point I tried to argue but it was apparently lost:
doing stack unwinding and cleanup on most Errors (some Errors like stack
overflow might not recoverable) is the best thing to do.
Because crashing is easy ( hek catch(Error) abort(42); ), but not
calling scope/destructors lays awful burden on programmer to do graceful
clean up. The it's granted that nobody will ever bother doing it.
The fun boys of "crush immediately" should just call special runtime hook:
crashOnError(true);
Or the make it the default, but do _allow_ proper stack unwinding (=
usual cleanup) after call to crashOnError(false).
--
Dmitry Olshansky
