On Thursday, 31 May 2012 at 02:18:22 UTC, Walter Bright wrote:
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.
I think this is a key point. Asserts are there to verify and
debug program logic, they are not part of the logic itself. They
are a useful tool for the programmer, nothing more.
Specifically, asserts are NOT an error handling mechanism!
If you compile the code with -release (which is often the case
for production code), the asserts won't even be included.
Therefore, when designing the error handling mechanisms for a
program, one should just pretend the asserts aren't there. There
is no point in writing code which shuts down "gracefully" when it
is compiled without -release, but trudges on in an invalid state
when compiled in release mode. Then you should have been using
enforce() instead.
-Lars
