Exception/Error division in D

[Lars T. Kyllingstad]

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