DIP33: A standard exception hierarchy

[Ali Çehreli]

On 04/02/2013 08:16 PM, Jesse Phillips wrote:> On Tuesday, 2 April 2013 
at 19:10:47 UTC, Ali Çehreli wrote:

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

An assert() is for situations that the programmer knows (!) to never 
exist. If my foo() function called my bar() function with 42, it is an 
invalid state. That is when assert() failed and threw Error.

The Error is not thrown before entering the invalid state but at the 
first point that the error has been discovered. In that regard, the 
program is in a bad state.

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

There are some issues with contract programming in D. For example, some 
people think that whether the pre-conditions of a module to be compiled 
should be determined by the user of that module, not the library (e.g. 
Phobos).

Because the above is not the case today, if I write a function, I cannot 
put the function pre-conditions in 'in' blocks because I don't know 
whether my function is being called as an implementation of my module or 
as an API function. The API function foo() may also be used as part of 
the implementation of the same module. (Maybe the same pre-condition 
checks should be repeated in the 'in' block and in the body; as asserts 
and corresponding enforces.)

For that reason, in general, I think that pre-conditions should by 
default be implemented as enforce() calls in the function body, not 
assert() calls in the 'in' blocks.

With that aside, a failed assert() in an 'in' block should still point 
at an invalid program state.

 > 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);

We are in agreement that it would be impossible to prove one way or the 
other whether removing the file would be the right thing to do or 
whether it will succeed. The difference in thinking is whether that 
should be attempted at all when some part of the code has determined 
that something is wrong with the program.

Ali