DIP33: A standard exception hierarchy

[Steven Schveighoffer]

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

> On Wednesday, 3 April 2013 at 14:32:59 UTC, Steven Schveighoffer wrote:

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

The problem with this is if you "weigh the benefit" in the library, then  
the user of the library has no choice.

Especially in phobos or druntime, we are disallowing libraries that build  
on top of them from saying "yes, I know this data is correct".  In  
essense, he is stuck checking user input, and then passing the data to  
your function, which checks it again.  There is no way out.

> 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 needs to be on a call-by-call basis, not a compiler-global.   
The same function could be called in the program twice, once with  
user-supplied data, once with static data.  In the former, I want to run  
the checks, in the latter, I don't.

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

No, I completely disagree.  It's very rare that you need bounds checks on  
data that is generated by the program.

Note that you can enable bounds checks by writing code in @safe D if  
that's how you wish to operate.

-Steve