Le 31/05/2012 11:23, Lars T. Kyllingstad a écrit :
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
Your are lost in the details of that specific case. assert is a very
specific issue. What is discussed here is much broader.
