Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?

[Frank W. Zammetti]

It is an accepted usage pattern that assertions are not to be used to 
validate method parameters if they are part of the public interface. 
They are properly used to check parameters passed to private members 
though, but nothing a calling client might send in (where a client isn't 
another part of commons for example).

Hope that helps!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Chris Lambrou wrote:
Hi,
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

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]