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. Stephen ----- Original Message ----- From: "matthew.hawthorne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> 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 anyway. > > --------------------------------------------------------------------- > 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]
