commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
Date Fri, 05 Nov 2004 23:27:26 GMT
The collections15 CVS looks good so far from a relatively quick look. The
main thing is to avoid the deprecated code and oddities like Bag (which you
seem to have done).

I wouldn't use assertions here, as you are trying to trap user input. (I've
never used assertions yet ;-)

Personally, I strive to avoid any NPE, preferring IAEs instead, but not
everyone in commons agrees with that philosophy. collections15 should make
one decision on that and stick by it.

Bear in mind that the JDK interfaces mandate NPE for null inputs.


----- Original Message -----
From: "matthew.hawthorne" <>
To: "Jakarta Commons Developers List" <>
Sent: Friday, November 05, 2004 3:54 AM
Subject: Re: [collections] Java5.0 - Runtime exceptions or assertion errors.
What's your preference?

> David Graham wrote:
> > The main reason not to use assertions is that they can be disabled at
> > runtime, rendering them fairly useless IMO.
> I think this was a fundamental goal of assertions.  I imagine that the
> idea is to enable assertions during heavy development time, and disable
> them once the code reaches a certain degree of stability.
> The enable/disable concept is appealing to some for performance reasons.
>   I think Sun claims that an assertion will have no performance cost if
> they are disabled.  I'm not sure how much of a difference it would make.
> > 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.
> I share your philosophy on this.  In my opinion, the redundant parameter
> checking everywhere (especially for null) does more harm than good.
> I like assertions, except in cases of input checking for a client
> external to the application (like a web service client, for example).
> I don't see the enable/disable as much of an issue.  The
> RuntimeException cases are supposed to be caught during development
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message