[kepler-dev] asserts in Java
cxh at eecs.berkeley.edu
Tue Dec 14 11:53:53 PST 2004
BTW - the caltrop facility in Ptolemy II is already using assert, so
as far as I'm concerned, it is ok to use assert now.
The biggest problem is the test coverage tool. I can look into that
Other than the few Ptolemy specific issues you addressed, I have arrived
at the same place you have.
And I think the extra (minimal) effort is worth the pay off.
On the Kepler end we pretty require 1.4.2_XX where XX is 05 or above (???).
I think we should set a date for when we can start using "asserts."
which should probably be driven by the Ptolemy folks, although we could
start to use them in Kepler sooner if wished.
Any other thoughts?
Christopher Brooks wrote:
>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
>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