Hi Gilles, 2012/9/17 Luc Maisonobe <luc.maison...@free.fr>: > Le 17/09/2012 11:50, Gilles Sadowski a écrit : >> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >>> OK, I give up. Lets do option 2. Just warn users in the User Guide >>> somewhere that our APIs are in general not null-safe and unless the >>> javadoc explicitly allows nulls, they can expect NPE when passing nulls. >> >> Thanks, Phil; we are making progress, and I hope that you'll be convinced of >> that at some point. >> >> Another decision still needs to be made. >> >> I think that everybody now agrees that wherever an argument will be directly >> used (i.e. "dereferenced") inside the body of the method[1], it is safe to >> not check for null (since the JVM will throw an NPE). >> >> But, whenever an argument is passed for _later_ use (e.g. stored by a >> constructor or passed to another method), we also all expressed that it is >> better to fail early if the object is supposed to be non-null. In those >> cases, checks are not mandatory (since the JVM will throw NPE at some >> point), but we must agree on how optional checks are to be implemented. >> 1. The current state of affairs was to throw "NullArgumentException"; in 4.0 >> this exception will become a subclass of NPE and we can continue to use >> it in the same way as now (i.e. possibly providing additional localizable >> error messages). >> 2. The alternative is to directly throw a standard NPE, but without any >> message, since it wouldn't be localizable with the support of CM's >> "context". >> >> So, which of those alternatives do people want to settle on? > > I would prefer 1. If we fail early, do it as precisely as possible. > > Luc > >> >> >> Regards, >> Gilles >> >> [1] As opposed to being passed on to another method. >> I would also be in favor of #1, so that any exception explicitely thrown by CM is one of our own exceptions. Sébastien
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org