DIP33: A standard exception hierarchy

[monarch_dodra]

On Monday, 1 April 2013 at 11:33:57 UTC, Lars T. Kyllingstad 
wrote:
> On Monday, 1 April 2013 at 11:23:50 UTC, monarch_dodra wrote:
>> On Monday, 1 April 2013 at 11:08:16 UTC, Lars T. Kyllingstad 
>> wrote:
>>> It's time to clean up this mess.
>>>
>>> http://wiki.dlang.org/DIP33
>>
>> A quick comment about your "Error" section. You say:
>>
>> "In general, Errors should not be caught, primarily because 
>> they indicate that the program logic is compromised, and that 
>> the program may therefore be in an invalid state from which 
>> there is no recovery".
>>
>> It is actually much worst than that: errors bypass the entire 
>> exception handling mechanism, blasting through code that would 
>> handle destructors, and even flying through functions that are 
>> nothrow. They don't just indicate a "potential" invalid state, 
>> they actually *put* the program in an invalid state, from 
>> which there is no recovery.
>>
>> That is the main mechanical difference between an "error" and 
>> an "exception", it is not just a philosophical "logic vs 
>> runtime".
>
> I had forgotten about that.  Personally, I think that is crazy.
>  Errors ought to propagate just like Exceptions, they just 
> shouldn't be a part of your "normal" error-handling mechanism.

I don't know, I find the approach kind of genius personally. If 
it is a logic error, and your program is going to die, then why 
pay for cleanup? You are getting the radical efficiency of a 
normal assert, but with the opportunity to die like with an 
exception.

The nicest part (IMO), is that thanks to this, you can assert in 
a nothrow function, without violating its nothrow-ness (which we 
do all over phobos, and even with built-in arrays).

>> --------
>>
>> Under this situation, I'm wondering how the "OutOfMemory" is 
>> dealt with (you don't explain). The only logical explanation I 
>> can see is:
>> - It is not an exception and is not caught by 
>> "catch(Exception)".
>> - But it is not an error either, so does not corrupt the 
>> program state.
>> => Goal: It is hard to catch, but you *can* recover from it.
>> Is this correct? Is this what we are going for?
>
> That was the idea, yes.

I like the idea, but it would be particularly breaking change for 
nothrow functions though:

void foo() nothrow
{
     try
     {
         throw new OutOfMemory()
     }
     catch (Exception /+e+/)
         {}
}

"Error: foo is nothrow yet may throw"

...what ...? But I caught the Exception!

The bypass would be giving OutOfMemory the same semantics as an 
Error, but then, it would just be an actual Error...