DIP33: A standard exception hierarchy

[Jesse Phillips]

On Tuesday, 2 April 2013 at 19:10:47 UTC, Ali Çehreli wrote:
> > 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 am not sure that I understand that comment correctly.)

(meant to say: we can still throw Errors in production.)

Errors currently really get used to identify conditions that 
could cause an invalid state as the check may not always be there.

> > 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.
>
> The problem is, the runtime cannot know that it will be doing 
> what you really wanted. The incorrect program state may result 
> in deleting the wrong file.

See above, the state isn't invalid. The error is thrown which is 
stating, "hey, buddy, good thing you didn't flip that release 
switch as I'm about to do something I shouldn't be."

However D does allow nothrow functions to throw Errors. I 
wouldn't say this would cause the program enter into an invalid 
state (memory corruption) but it would be a bad state (contract 
violations).

Take the RangeError thrown when you pop an empty range. Under 
what scenario would receiving one of these would indicate that my 
file isn't correct for deletion (any more so than say a 
ConvException from the same range).

     auto myFile = "some.tmp";
     scope(exit) remove(myFile);

     // setup code here
     manipulateFileRange(range);

setup code could of course assign a pointer of myFile to range 
and range could make modifications but doing so could just as 
likely throw a ConvException (or others) before you hit a 
RangeError.