Exception/Error division in D

[deadalnix]

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.