[kepler-dev] asserts in Java

Christopher Brooks cxh at eecs.berkeley.edu
Tue Dec 14 11:17:10 PST 2004

Yah, I've been thinking it would be nice to use assertions.
The following issues have been holding me back.

1) The very old code coverage tool we use locally fails to handle
files that have assert statements in them.  I could hack around
this, or I could get a better coverage tool.

2) Use of assert requires compiling with -source 1.4, for example
   javac -source 1.4 Foo.java
This would require updating how we build with make and Eclipse.
This change is not a huge change, but it just adds complexity
to the Eclipse instructions.

3) There are probably some odd platforms that do not have a Java
1.4 compiler.  However, Ptolemy II requires 1.4 because we use
the java.net.URI package.

4) There are issues concerning assertions and testability.  Ideally,
error conditions should be tested to make sure the error message makes
sense and does not in itself throw an unexpected exception.  I think
testing assertions can be a little bit more tricky than testing
regular exceptions, though I'd need to think about it more.

That being said, I think it is worth it.  

In particular, when writing tests, I've noticed that there are
a few places where we throw internal error exceptions because a
block should never be reached.

The problem is that the test case coverage marks these blocks
as untested.  

Perhaps if we used assertions, we could work around this?

At least the unreached blocks would have an assertion there,
which indicates that we should never be running that code.

A couple of caveats about assertions:

1) They are not always run, so there should be no side effects.

2) It is considered to be in poor taste to use assertions to test the
validity of arguments of public methods, instead assertions should be
used to test arguments of private methods.



    I was wondering if there was a reason we were not using "asserts" that 
    became available in the JDK 1.4?
    Just as in C++ I think there can be a lot of utility in feature.
    It would appear that they are always off and that we can turn them on 
    for development runtime enabling us to catch things without incurring 
    the overhead.
    kepler-dev mailing list
    kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list