commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Date Sat, 05 Mar 2011 19:22:09 GMT
Sure - For example the LaguerreSolver has the following set of lines in the start of the solveAll
method:

         if (coefficients == null) {
             throw new NullArgumentException();
         }
         int n = coefficients.length - 1;
         if (n == 0) {
             throw new NoDataException(LocalizedFormats.POLYNOMIAL);
         }

Move these to a Validator class (Could be an inner class of the LaguerreSolver) that has a
validateSolveAll method in it:

     public void validateSolveAll(Complex coefficients[], Complex initial)
     {
         if (coefficients == null) {
             throw new NullArgumentException();
         }
         int n = coefficients.length - 1;
         if (n == 0) {
             throw new NoDataException(LocalizedFormats.POLYNOMIAL);
         }         
     }

Now if you are the client you would do:

validateSolveAll(..)
solveAll(..)

If you are a user interface designer you would wrap the validateSolveAll in a validator for
the user interface framework being used to provide real time feedback to the user.  It makes
life easier for the GUI Designer because the validation exceptions have been separated from
other types of exceptions, like a ConvergenceException.

Cheers,
- Ole

On 03/04/2011 05:32 PM, Gilles Sadowski wrote:
> Hi.
>
>> Just want to throw another idea into the mix.  How about stripping all the validation
argument validation lines and putting in separate validator classes.  Clients would call the
validator on the arguments for the class before passing the arguments to the class's method.
 It makes the core classes more focused and efficient and enables clients to wrap method invocations
with aspects that apply the validation routine.
>
> Could you post a little code example?
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message