DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

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.


> --------
>
> 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.