Re: check for empty Strings

From: Chris Smith (cdsmith_at_twu.net)
Date: 12/14/03 

Date: Sun, 14 Dec 2003 15:27:59 -0700

Alex,

Hate to disagree, but...

Alex Hunsley wrote:
> > A little note here on String comparison: reversing the order of items in
> > an equals() call can be a useful defensive technique.
> >
> > For example, suppose you have a String called lastName. If it's set to
> > null, the following code will crash out on a Null pointer reference:
> >
> > if (lastName.equals(""))
> >
> > So, in order to fix the Null pointer situation, you could write:
> >
> > if (lastName != null && lastName.equals(""))
> >
> > However, you can do away with the null check completely by writing:
> >
> > if ("".equals(lastName))

This code will do exactly the same thing whether lastName is null or
non-empty, but do something else if it's non-null or empty. That's such
an unusual branch condition, really, that I'd rather see it said
uniquely, e.g. as:

    if ((lastName == null) || !lastName.equals(""))

Or, do you often encounter the need to do one thing in the null-or-
nonempty case, and something else in the empty string case. In any
case, use of this very unusual condition should never become a default
when you haven't thought about the correct behavior for null in that
scenario, or when null is not a valid input.

and later:
> on the other hand, if lastName should *never* be null, by writing the
> original:
>
> if (lastName.equals(""))
>
> you'll pretty quickly find out if it ever *is* null.
> However, in this case, you're better off checking for null explicitly
> and flagging some sort of error/exception of your own.

I definitely disagree here (with that last sentence). There are many,
many cases where code is written that uses a reference, and assumes that
the reference is not null. In fact, that probably constitutes upwards
of 90% of all references in top-level code units (methods, constructors,
instance and static initializers, etc.), and upwards of 99% of actual
dereferencing of a reference variable in Java code. If every single
such use of a reference were preceeded by an if and explicit throw of
and exception, code would be well-nigh impossible to read. Even every
top-level code unit beginning with such a statement would be rather
extreme.

Not to nag you, Alex. I just fear the spread of Placate The Compiler
Syndrome (or, in the case, the related Placate The VM Syndrome), which I
fight on a daily basis when working with development teams to try and
improve their defect rates and quality of code. Adopting coding styles
that hide errors is a bad idea, and a prejudice against runtime crashes
and in favor of silent data corruption is something to fight, not
support. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: check for empty Strings
    ... feel free disagree whenever you see a valid reason to! ... Returns false if lastName is null or a different string to "" ... > the reference is not null. ...
    (comp.lang.java.help)
  • Re: C# Nullable types
    ... Kevin Spencer wrote: ... or reference to data of a given type is unassigned, ... I'd disagree with that - being unassigned is very different to being ... string x = null; ...
    (microsoft.public.dotnet.framework)
  • Re: Complex Specified Information - Pitman Formula
    ... Therefore a significant match between a reference and a test ... string is good evidence of non-random production. ... and there are no finite algorithms to compute their digits. ... probabilities of the different symbols the information source can produce. ...
    (talk.origins)
  • Re: String Reference Type
    ... All unary and binary operators have predefined implementations that are ... Therefore its always allocated in the heap and a variable of string ... As with all classes in this case y and x both reference the same String ... language depandant matter as below. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Abstract class variables question
    ... But as I think you've seen elsewhere in this thread, a value type can exist inside a class and in that case the value type is stored in the heap with the rest of the class instance. ... But as far as the "faster" goes, yes...to some extent value types have less overhead than reference types, and so can perform better in certain cases. ... Well, that would be true for a string object too, if there was any way to actually change a string. ... Seriously though, it is practically always the case that when you are writing an assignment to a reference, you're replacing the reference held by the variable. ...
    (microsoft.public.dotnet.languages.csharp)