Re: About using assertion
Robert Klemme wrote:
Lew, I am not sure what you tried to convey with this posting. I for my part
would say that the assert is a tad too much here since the if clause before
that gives me enough "confidence" that arg is actually >= 0 at that line. If
First, the example is deliberately simple to highlight the structural location
for 'assert' statements. Formally, they go where invariants are.
The exception gives that confidence, yes, but only just now at code-inspection
time. At this level, the assertion provides not much more than
compiler-enforced documentation of the invariant. However, refactoring,
inheritance and other future actions could violate the invariant. This would
manifest in production, where source code is not immediately convenient.
Ops guys can use assertions to locate which invariants were violated, helping
diagnose and triage the problem.
it isn't then I have bigger problems than calculating square roots of negative
numbers. :-)
True but only at one moment in time. Assertions live ongoingly and can be
re-enabled at trouble time.
It's probably a different story if the calculation is done by a private method
in which case I'd probably add the assert to the beginning of that method just
to be sure the caller (which can only be in the same class or nested classes)
did not make a mistake.
There is art in the decision of which invariants to document. I like to
document all of them. Why not? Others only document a few. Why? I've been
on the ops end of production code quite a few times, so I find assertions
valuable. I studied math way back when, and I appreciate their formal value.
Pragmatically there is no reason to avoid them, and good reasons to use them
liberally, if strategically.
There is no real art to deciding where assertions go if you do use them. They
go at the algorithmic invariant points. I assert that you should use them
wherever they support operations, and in the largest proportion of invariant
points consistent with that goal. That is a matter of your strategy and style.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg