On Thu, 4 Nov 2004 18:19:32 -0800 (PST), David Graham
<[EMAIL PROTECTED]> wrote:
> The main reason not to use assertions is that they can be disabled at
> runtime, rendering them fairly useless IMO. Personally, I would remove
> the null parameter checking entirely and let the code throw a NPE. The
> caller will see their offending method in the stack trace.
Assertions are actually disabled by default, and need to be explicitly
enabled at JVM startup time. To make things worse, specifying a flag
to the JVM on startup can be complicated when an app server is
involved.
In my day job, we looked into using Java assertions when we could
finally depend on JDK 1.4 or later, and chose to eschew them in favour
of our own homegrown assertion class for the reasons above.
--
Martin Cooper
> David
>
>
>
> --- Chris Lambrou <[EMAIL PROTECTED]> 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]
> >
> >
>
>
> __________________________________
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>
>
> ---------------------------------------------------------------------
> 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]
