Conversely you could create a Required<T> class that fails when a null is used, properly documenting that a parameter is required.
Martijn On Wed, Jan 5, 2011 at 6:44 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > ive recently ran into a few cases where while implementing > ajaxfallbacklink i forgot to test the passed in request target for > null, causing NPEs when the app was accessed from browsers where ajax > failed for whatever reason. > > with all this talk of scala recently i figured why not try and > translate one of the feature i really like in scala Option/Null/Some > to our code base. > > i came up with a simple value class: > https://gist.github.com/c38456ee75fed541c932 > > and changed the ajaxfallbacklink to use it > https://gist.github.com/2f648c7feacacf18fc40 > > the cascade from this change was pretty impressive, a lot of places in > our code support passing a possibly null request target but make no > mention of it: > https://gist.github.com/d9933e24c21f061c6ac2 > > so advantages: > makes possible null value handling explicit > no more checking the javadoc to see if the method supports null as a > parameter value or ever returns a null > an api break before 1.5 rc1 > i think overall makes lives of wicket users easier > > disadvantages: > a bit wordier code > an api break just about when we are ready to release 1.5 m4/rc1 > whatever we call it > > yay or nay? obviously if we say yay there are a lot more places in our > code that can benefit from this > > -igor > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
