Re: check for empty Strings
From: Chris Smith (cdsmith_at_twu.net)
Date: 12/15/03
- Next message: Jim: "Unable to locate function name symbol"
- Previous message: AtoBAD: "A problem with using IDE"
- In reply to: Alex Hunsley: "Re: check for empty Strings"
- Next in thread: Shane Mingins: "Re: check for empty Strings"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 15 Dec 2003 08:59:22 -0700
Alex Hunsley wrote:
> > but do something else if it's non-null or empty.
>
> No. You've misdescribed it.... it won't do "something else if it's
> non-null or empty", it will do something else only if it is empty (which
> implies non-null).
Indeed, I meant to write "non-null and empty"... I don't know how the
word "or" crept in there. Sorry!
> > 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.
>
> I think you've misunderstood something here.
> My code doesn't test for "null or non-empty".
Sure it does. We're looking at three cases here:
1. null
2. ""
3. "not empty"
The test is:
if ("".equals(str)) ...
That will do one thing for case 2 (empty) and another for case 1 or 3
(null or non-empty). So yes, your code takes one branch if a string is
null or non-empty, and a different branch if it's neither (meaning, it's
empty).
> I'm not intending that people throw an exception every time a String is
> null (and it's innaproriate), sorry if I gave that impression. However,
> if the String is very critical to things, it's sometmies worth checking
> perhaps and altering the code flow or doing something differently.
Oh, I actually *am* suggesting that it would be a good idea for an
exception to be thrown any time that a String is inappropriately null,
and that's quite crucial. In fact, it's exactly that reason that I'm in
favor of forming habits in coding style that make it more likely that
exceptions will be thrown when something inappropriate happens at
runtime.
What I disagree with is the idea of doing those checks and exceptions
*manually* everywhere that they should happen. Hence, when you said:
> >> 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 disagree. I agree with the goal of finding out quickly that a String
is null when it's not supposed to be so; but except in a *published*
public API, I think checking explicitly is mostly overkill. Instead,
adopting a general style that catches these kinds of anomalies is far
less intrusive, and quite effective. It also is more likely to catch
logic errors within a method, where you're almost certain not to add
explicit checks for the null-ness of a variable. For example, it's not
un-heard-of (far from it, in fact!) for a programmer to be mistaken
about the possibility that some API element will return null. In that
case, the programmer would have to anticipate their own error to add the
explicit check, and if the error is anticipated, then the programmer
will simply check documentation and avoid the error in the first place.
So, for this reason, I'd rather see people shun and avoid development
styles that decrease the likelihood that incidental errors will cause
definite and visible failure.
> It's my view that if a String *can* be null, and that is an allowable
> situation, then the test:
>
> "whatever".equals(stringVariable)
>
> is simply a shorter way of writing:
>
> stringVariable != null && stringVariable.equals("whatever")
Ah! If the constant string being tested against is not empty, then this
makes a bit more sense. In that case, it's quite likely that the null-
or-not-equal case fits together, and the matching case is different.
Nevertheless, I'd still prefer -- in my own projects -- to see the
possibility of null brought out explicitly by writing the latter form;
but I can see how others may differ on that one.
-- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
- Next message: Jim: "Unable to locate function name symbol"
- Previous message: AtoBAD: "A problem with using IDE"
- In reply to: Alex Hunsley: "Re: check for empty Strings"
- Next in thread: Shane Mingins: "Re: check for empty Strings"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
