Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <418AD3A5.2050906@omnytex.com>
Date: Thu, 04 Nov 2004 20:13:09 -0500
From: "Frank W. Zammetti" <fzlists@omnytex.com>
Reply-To: fzlists@omnytex.com
Organization: Omnytex Technologies
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
 What's your preference?
References: <2B64219028BBFF48B3CC957EF10B58FE309C3A@ns1018.SSSI.seagull.nl>
 <001f01c4c135$56573600$bc739951@oemcomputer>
 <418AD2C2.3040403@chrislambrou.com>
In-Reply-To: <418AD2C2.3040403@chrislambrou.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org