Re: use of assert in Java [vs. exceptions]
On 30.05.2009 12:46, Giovanni Azua wrote:
Before moving into the concrete arguments I wanted to present the following
definitions by Bertrand Meyer:
Defensive programming: "A technique of fighting potential errors by making
every module check for many possible consistency conditions, even if this
causes redundancy of checks performed by clients and suppliers. Contradicts
Design by Contract." [1, p1195]
Design by Contract: "A method of software construction that designs the
components of a system so that they will cooperate on the basis of precisely
defined contracts. See also: defensive programming." [1, p1195]
"Assertion Violation rule (1) A run-time assertion violation is the
manifestation of a bug in the software." [1, p346]
The key in the defensive programming definition is "check". It doesn't
really matter what is done after encountering the problem either throwing
exceptions or programming an alternate way e.g. Math.sqrt that handles the
special case of negative input by returning Double.NaN. Please note that
neither Eiffel "require" nor the Java "assert" for verification of pre
conditions would fall under the category "check", by definition Design by
Contract (DbC) is not a check, they are enabled only optionally and for
discovering programming errors. Granted that Java assert feature is a small
subset of what Eiffel DbC offers [3, p15 "So, is it like 'assert.h'"].
The point I was defending was that Sun's commended way to use assertions was
too categorical "Do not use assertions to check the parameters of a public
method" [2]. The reasoning for my discrepancy towards that rule is that
programs should not handle pre condition violations that are rooted in
programming errors by means of exceptions e.g. IllegalArgumentException.
However, the case of user input validation is a good use-case for using
IllegalArgumentException.
Actually, if you write a library that is distributed as a jar the code
must check input into public accessible methods always and handle them
appropriately. This often means throwing an IllegalArgumentException
but it may also mean returning a special value such as NaN. Which
approach is more appropriate depends on the situation. But the code
needs to do this in order to maintain integrity of its internal state
(class invariants for example). Now, considering that a class is a
module much the same way as library every public method of it is part of
its API and marks the border between "outside" and "inside".
Basically this means that all public and protected methods need some
form of argument checking and dealing with illegal data. Other
languages have other means but since Java does not support DbC in the
language you have to use the features that you have.
IMHO you should only use assert for input checking if a) performance is
paramount _and_ b) you have _system_ test coverage that includes
combinations of all classes of correct and incorrect input data and all
possible invocation paths. This means that for most Java applications
out there (which do not play in the field of space mission control or
high performance realtime processing) you would rather have checks with
exceptions than using assert for input checking.
Personally I often use assert in situations where non trivial
calculations are done and I would have used a comment in pre Java 5.
The nice thing about assert is that you do not pay the performance
penalty in production while retaining a relatively short expression
which also helps documenting. For example
Collection<Foo> foos = ...
... complex processing here which must eventually empty foos ..
assert foos.isEmpty();
In general, exceptions are meant to be handled
programmatically. You can't nor should recover from programming errors but
rather *fix* them e.g.
This is the precise reason why there are checked and unchecked
exceptions in Java. Similarly to Error and subclasses unchecked
exceptions should be handled programmatically only in relatively rare
cases, e.g. in a testing framework or in an application which must keep
running under all circumstances (e.g. a JEE container which must not
break just because a single application of potentially many deployed
applications runs berserk).
A few excerpts from Bertrand Meyer's book:
"Non-Redundancy principle: Under no circumstances shall the body of a
routine ever test for the routine's precondition." [1, p343] For the example
that depicts such case he writes "is not just unnecessary but unacceptable"
[1, p343]
You need to keep on mind that this is in the context of his book where
he presents Eiffel. (Btw, it seems you got the quote numbering wrong,
this must be from OOSC which is [2] in your posting.) With a language
that provides rich DbC support and declarative pre- and postconditions
it is of course nonsense to check those inside method bodies.
"Aside from performance considerations, however, the principal reason to
distrust defensive programming is simply our goal of getting the best
possible reliability. For a system of any significant size the individual
quality of the various elements involved is not enough; what will count most
is the guarantee that for every interaction between two elements there is an
explicit roster of mutual obligations and benefits - the contract. Hence the
Zen-style paradox of our conclusion: that to get more reliability the best
policy is often to check less." [1, p345]
This still means that you need _some_ form of automatic checking of this
contract so you can detect violations. _How_ this checking is done is a
highly programming language dependent issue. In Eiffel you have DbC
support, in Java you have assert, checks and exceptions.
"Lew" <lew@lewscanon.com> wrote
The method [Math.sqrt] must handle the illegal input. No amount
of concern for "performance" relieves it of responsibility to
handle a negative input.
"Such a comment, however, comes from a microscopic understanding of
reliability, focused on individual software elements such as the sqrt
routine. If we restrict our view to the narrow world of sqrt, then the
routine seems more robust with the extra test than without it. But the world
of a system is not restricted to a routine; it contains a multitude of
routines in a multitude of classes. To obtain reliable systems we must go
from the microscopic view to a macroscopic view encompassing the entire
architecture." [1, p344]
I can agree to that one although I find the statement very vague. And:
looking at the entire architecture does not make Lew's point invalid
that your microscopic checks need to be there - one way or another. You
cannot build a house on individual components that do not deliver
advertised quality.
I hope all the excerpts and explanations illustrate my point.
Frankly, with all the quotes I am not sure what _your_ point really is.
You seem to advocate to drop what has been called "defensive
programming" in your article but since I did not follow the other thread
my insights into your own reasoning are limited.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/