DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

On Wednesday, 3 April 2013 at 05:42:13 UTC, Lars T. Kyllingstad 
wrote:
> The problem with assert is that it gets disabled in release 
> mode.
>  I think it is a bad idea to have this be the "standard" 
> behaviour of parameter validation.

Allow me to clarify my position on assert() a bit.  As a general 
rule, I think assert() should be used to verify internal program 
flow and program invariants, and nothing more.  Specifically, 
public APIs should *not* change depending on whether asserts are 
compiled in or not.

Say I am writing a function that you are using.  I don't trust 
you to always give me correct parameters, so I check them.  
(Maybe my function could even do something dangerous if I didn't.)

   public void myFunction(someArgs)
   {
       if (someArgs are invalid)
           throw new InvalidArgumentError;
       ...
   }

Now that I have verified that your input is correct, i.e. that 
your part of the deal is done, everything that happens afterwards 
is entirely up to me to get right.  And *that* is when 
assertations enter the picture.  I'll sprinkle my code with 
assert statements to make sure that every step of whatever 
procedure myFunction() performs is correct, and I may use it to 
verify input parameters to *private* helper functions and such.  
These kinds of checks are purely for my personal use, for 
debugging and for verifying that changes I make do not break 
other parts of the code.

There may of course be situations, e.g. in performance-critical 
code, where it is desirable to disable parameter validation, but 
then -release should not be the switch that does it.
-version=TotallyUnsafeButVeryPerformantDudeYourAeOnYourOwnNow, 
anyone? :)

Lars