DIP33: A standard exception hierarchy

[Steven Schveighoffer]

On Wed, 03 Apr 2013 01:59:32 -0400, Lars T. Kyllingstad  
<public at kyllingen.net> wrote:

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

I disagree here.  There are two "users" involved, one is the actual user,  
typing a command on the command line, and then the developer who uses the  
function.  The developer should be checked with assert, the user should be  
checked with code like you wrote.

The problem becomes apparent when developers don't check user input before  
passing to your functions.  That is on them, not you.  The library should  
be able to have all the safety checks removed to improve performance.

I wish there was a way to say "this data is unchecked" or "this data is  
checked and certified to be correct" when you call a function.  That way  
you could run the in contracts on user-specified data, even with asserts  
turned off, and avoid the checks in release code when the data has already  
proven valid.

-Steve