I think NullArgumentException should be deprecated and removed. It is becoming a best practice to use NPE for null arguments. Joshua Bloch has produced two books containing such advice, and Google Collections has gone this way too. By the way, it's because the JDK has set this precedent.
Paul On Mon, Jul 20, 2009 at 1:12 PM, Henri Yandell<flame...@gmail.com> wrote: > Hi Stephen :) > > On Sun, Jul 19, 2009 at 11:35 AM, Stephen > Colebourne<scolebou...@btopenworld.com> wrote: >> Henri Yandell wrote: >>> >>> 1) All the exceptions are in lang.* rather than lang.exception.*. Now >>> that the subpackage is pretty empty, it's tempting to move the >>> exceptions themselves down there. Given that it's going to be a >>> different package (ie: lang3 not lang), this seems doable. Probably >>> best to only do it when trunk changes to lang3. >> >> I'd prefer to see the subpackage removed and the exception classes stay put. > > So moving ExceptionUtils up. I'm fine with that too. > >>> 2) NullArgumentException >> >> I've never quite convinced myself that [lang] can make this exception work >> alone. However, I suspect that some teams will have used it widely in their >> own standards. As such, I'd suggest keeping it in [lang], but continuing to >> not use it - closing LANG-52 as WONTFIX. > > How about putting in the backcompat? > >>> 3) IllegalClassException. I think that, generally, this has been >>> replaced by generics. Again my urge is to delete and have the much >>> smaller use case of examples simply use IllegalArgumentException. >> >> There are still plenty of places where generics doesn't work (or where you >> need to check for invalid values passed in by raw types. > > Fair enough. > >>> 4) IncompleteArgumentException. The same problem of hardcoding text in >>> the message. Not feeling like it offers much to the user. >>> >>> 5) NotImplementedException does have hardcoded text, but it is in a >>> sufficiently optional version of the constructor. >> >> In general, I'd keep these exceptions. But if they are to be removed, I'd >> try and remove all of them. > > Happy on the #5; #4... I don't like the hardcoded text and can't think > how to clearly fix things without a name change. Also doesn't seem as > valuable as others. > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
