DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

On Wednesday, 3 April 2013 at 14:32:59 UTC, Steven Schveighoffer 
wrote:
> On Wed, 03 Apr 2013 01:59:32 -0400, Lars T. Kyllingstad 
> <public at kyllingen.net> wrote:
>>
>> 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.

Some, yes, but not all.  You always have to weigh the benefit, 
i.e. the improved performance, against the drawbacks, i.e. 
reduced safety.  If you are removing trivial safety checks from a 
function that performs a very expensive and possibly dangerous 
operation -- a disk operation, say -- you're doing something 
wrong.

I agree it should be possible to remove safety checks from 
functions which are expected to be performant, and where the 
checks will have an impact (e.g. the range primitives), but it 
should be done with a less attractive compiler switch than 
-release.

I think it's a big mistake to encourage programmers to ship their 
programs with array bounds checks and the like disabled.  Such 
programs should be the exception, not the rule.  It's always 
better to err on the side of safety rather than 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.

That would be awesome indeed.

Lars