Thanks Matt, Simo! I've updated the code to use Validate.notNull and removed unreachable code. Tests were created as part of FUNCTOR-12 [1]. The issue was resolved today, with line coverage of 99% and branch coverage of 96% (not being crazy about coverage, just tried to cover important parts of the code :-).
Cheers, [1] https://issues.apache.org/jira/browse/FUNCTOR-12 Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com >________________________________ > From: Matt Benson <gudnabr...@gmail.com> >To: Commons Developers List <dev@commons.apache.org> >Sent: Tuesday, 24 July 2012 12:46 PM >Subject: Re: [functor] Use Validate.notNull and remove unreachable code > >+1 to all FWIW > >Matt > >On Tue, Jul 24, 2012 at 4:28 AM, Simone Tripodi ><simonetrip...@apache.org> wrote: >> Olá Bruno, >> >>> 0) I would like to add the method Validate.notNull(...) where necessary in >>> [functor], if no one objects. Right now, I'm working on the following >>> composite functors: TransformedProcedure, TransformedFunction, >>> TransformedBinaryProcedure and TransformedBinaryFunction. None of these >>> validates the arguments, while OTOH, TransposedFunction, >>> TransposedPredicate and TransposedProcedure, classes in the same package, >>> use Validate.notNull(...). >> >> +1 >> >>> 1) There is also unreachable code, specially in equals() methods, that >>> checks if an object is null before accessing its methods. But this object >>> can never be null, as Validate.notNull(...) or throw NPE is used to assert >>> this in the constructor. There is no other way to set this object. (You can >>> still change it through reflection, but don't think it is worth keeping it >>> only for this reason). I was wondering if we could remove the unreachable >>> code, as there is no way to write test code for it. [2] is an example of >>> unreachable code (one of its conditions), with the tests in [3] (there is >>> no way to have a null predicate). It will simplify the code, reducing >>> decision branches and will increase the test coverage too. >> >> sounds reasonable too, looking forward to see results! >> >> best, >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> --------------------------------------------------------------------- >> 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
