we have adopted a required-by-default style, which is correct imho. only a few places in our code are allowed to return null and Optional is a simple way to document them directly in our code.
-igor On Wed, Jan 5, 2011 at 10:36 AM, Martijn Dashorst <martijn.dasho...@gmail.com> wrote: > 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 >
