On Fri, 25 Mar 2011 23:17:53 -0400, spir <denis.s...@gmail.com> wrote:
On 03/25/2011 09:49 PM, Steven Schveighoffer wrote:
On Fri, 25 Mar 2011 16:23:08 -0400, spir <denis.s...@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
