commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lambrou <>
Subject [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Date Fri, 05 Nov 2004 01:09:22 GMT

Although I've marked the subject with [collections], I guess this is 
targeted at anyone who has an interest in a Java 5.0 port of any jakarta 
project. I'm slowly chipping away at a Java 5.0 port of 
commons-collections.  As I've been generifying the original collections 
classes, I've found apart from a little bit of tidying here and there, 
I've mostly been leaving the argument checking code at the start of most 
constructors and/or factory methods alone.  It's just occured to me that 
all of these checks are explicit checks that throw some subclass of 
RuntimeException. For example:

    protected ClosureTransformer(Closure<? super E> closure)
        if (closure == null) {
            throw new IllegalArgumentException("Closure must not be null");
        this.closure = closure;

Since JDK1.4, the assert keyword has been available to replace this type 
of error checking, but obviously it's not been used in collections in 
order to maintain backwards compatibility with earlier versions of the 
JDK.  With the move to Java 5.0, backwards compatibility is no longer a 
concern, and I'm considering replacing all such runtime argument checks 
with assertions. For example:

    protected ClosureTransformer(Closure<? super E> closure)
        assert closure != null : "Closure must not be null";
        this.closure = closure;

I've heard both sides of the explict-check-and-RuntimeException versus 
Assertions argument before in what feels like the dim and distant past, 
but the discussion has always included the backwards compatibility 
slant.  I was wondering if anyone has any thoughts on the matter in 
light of Java 5.0


P.S.  If anyone's interested, the JDK 1.5 port of collections is 
currently hosted on SourceForge at 
- I'd be interested in any feedback, particularly on the new generic 
interfaces in the main package.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message