against enforce

[Steven Schveighoffer]

On Fri, 25 Mar 2011 23:17:53 -0400, spir <denis.spir at gmail.com> wrote:

> On 03/25/2011 09:49 PM, Steven Schveighoffer wrote:
>> On Fri, 25 Mar 2011 16:23:08 -0400, spir <denis.spir at gmail.com> wrote:
>>
>>> This logic certainly looks sensible, but I cannot understand how it  
>>> should
>>> work in practice. Say I'm implementing a little set of operations on
>>> decimals. Among those, some (division, square root...) will  
>>> necessarily have
>>> to check their input.
>>
>> You can look at it in a simple way: If this branch of code will always  
>> run the
>> same way every time (i.e. is deterministic), then using assert is  
>> desired. Why?
>> Because the assumption is that you test that code via unit tests. Once  
>> you test
>> it, and it works, there is no reason to test it again.
>>
>> For example, if I do:
>>
>> sqrt(1);
>>
>> There is never ever a need to test this in production code. sqrt(1) is  
>> always
>> 1, and will always work.
>>
>> If I do:
>>
>> sqrt(-1);
>>
>> There is never ever a need to test this in production code. sqrt(-1) is  
>> always
>> a failure, and will always fail. Unit tests should catch this code  
>> before it is
>> released.
>>
>> But if I do something like:
>>
>> auto file = File.open("/tmp/xyz.txt"); // did not look up usage for  
>> File, may
>> be wrong
>
> I agree with all of this. But here you're the client of sqrt. What if  
> you implement it (or for a new numeric type)? You'll need to catch param  
> errors for /input/ to your func (not for args you /provide/ to a third  
> party func). That was my case.

The issue isn't so much that you should or should not catch errors, the  
issue is, can the error catching be *optimized out* at production time.   
The answer to that question is impossible for a compiler to answer,  
because figuring out where a parameter came from I believe is the halting  
problem, and impossible (currently) for a developer who can figure out the  
answer to handle.

This is really a question of optimization, not error catching.  If  
something will always be the same, and it has already been tested, there  
is no reason to test it again.

-Steve