commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [lang] StringUtils.containsOnly
Date Thu, 26 Sep 2002 19:25:34 GMT
Steve Downey wrote:
> On Thursday 26 September 2002 01:23 pm, Berin Loritsch wrote:
>>Stephen Colebourne wrote:
>>>I go further than this - in my world a product like [lang] would never
>>>throw NPEs. If it did then that would be a bug. If null is a disallowed
>>>parameter then that should be checked and thrown as an
>>>IllegalArgumentException. But thats just my coding style.
>>>Its probably a pity that we didn't agree a uniform approach to this, but
>>>its too late now. The priority is to document what we have correctly.
>>I have to agree with you on both of your points Stephen.  NPE's are
>>indicative of something terribly wrong.  To me it is the Java equivalent
>>of the C++ pointer error.  At least with an IllegalArgumentException,
>>you know you skrewed up using the method.  An NPE could mean anything
>>from an illegal argument (see, IllegalArgumentException) to the method
>>is just completely foo-barred.  I reserve NPEs for things that are
>>foo-barred and IllegalArgumentExceptions for wrong arguments.
> Well, I agree with you, Berin, and disagree with Stephen, I think. 
> As I understand it, Stephen is arguing that StringUtils should never throw a 
> runtime exception when presented with null. I'm arguing that it should. The 
> runtime exception that java.lang.String throws in similar situations is NPE. 
> IllegalArgumentException is starting to be adopted by other parts of the API 
> for null arguments, eg JAXP, however. It was originally used for exceptions 
> like undefined locale, or where an int is used as an enum and the argument 
> wasn't one of the defined enums.
> If it is a case of arg == null, that can make sense. However, checking every 
> object before access for being == to null, and converting that to a different 
> exception leads to messy code. 

Well, there is always this snippet:

public Handler createHander( String name, URL location, Class klass )
     if ( null == name ||
          null == location ||
          null == klass )
         throw new IllegalArgumentException( "Cannot have any null

     // ....

I have seen a number of factory methods or methods with several
paramters perform this bulk null check.  I have also seen the creation
of Validator classes.  The Validator class would both ensure nothing was
null, and make sure methods were called in the proper order.  The above
code would be rewritten using a Validator like this:

public Handler createHandler( String name, URL location, Class klass )
     FactoryValidator.checkCreate( name, location, klass )

     // ....

It cleans up the critical path for the code quite a bit while allowing
you to perform meaningful exceptions.  It's more work, though.

> I don't like treating null as "", which is the common 'solution' to avoiding 
> NPEs. For example, in str, int size), which embeds 
> str in the center of a string of length size, right now you get an NPE if you 
> call, 80). You shouldn't ever call the method with 
> null. It's not meaningful. I wouldn't like to see it return a string with 80 
> spaces.

It really depends on the usage.  When I have a class that has several
arguments in the constructor, I use several constructors and fill in the
blanks with reasonable defaults.  It works well--but you have to
document what the defaults are.

In this case, you are probably right.  It is not meaningful to center an
empty string either, but it is easier to code a loop that way:

while ( line = in.readLine() != null )
     System.out.println( line, 80 ) );

Then again, what is the *harm* in converting null to an empty string?
Is the harm worse than throwing an exception?  In the center() method,
there is no real harm.  For something else, there may be some real harm.
If there is real harm, I always throw an exception.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message