DIP33: A standard exception hierarchy

[Jesse Phillips]

On Monday, 1 April 2013 at 22:46:49 UTC, Ali Çehreli wrote:
> But I also remember that an AssertError may be thrown by an 
> assert() call, telling us that a programmer put it in there 
> explicitly, meaning that the program cannot continue. If there 
> was any chance of recovery, then the programmer could have 
> thrown an Exception or remedy the situation right then.
>
> Ali

I don't think assert/Error makes any statement on the ability to 
recover. What it usually means is you need to fix this because I 
won't be checking this condition when you throw on that release 
flag.

If you are doing input validation you should be throwing an 
exception.

We can still throw exceptions in production, I don't tend to use 
this, but maybe this would be a time to say "invalid state stop." 
But then how do you distinguish it from "fix your program?"

I've mostly enjoyed having temporary files being cleaned up upon 
some range access error which has no effect on my removing files 
that are no longer valid.