• anon (unregistered) in reply to odi
    odi:
    pitchingchris:
    Since it can't be both null and blank at the same time on todays computers

    You know Oracle? I love the fact that an emptry string is null...

    emptry string is null? is there i_hate_oracle club somewhere guys...

  • 10 (unregistered)

    The real WTF is that you're all having a debate over the necessity of testing NULL and empty when the thing that's wrong with the code of the guy is simply that these tests have absolutely no use. It's like writing : if (isDead(grandma)) stompToDeath(grandma); Just to be sure huh?

  • Russell VT (unregistered) in reply to pitchingchris

    You've probably never written code in PHP, where things like "empty" (eg. null) actually mean no-value or, at least, not equal to zero. cough

    Similar issues happen for trying to find NULL values in MySQL, though they're a little more sensible (IMO).

  • (cs) in reply to Nonymous
    Nonymous:
    Malfist:
    Or is java: reportGroup = (reportGroup == null || reportGroup.equals("")) "" : reportGroup

    You're missing a ? in your ternary expression.

    Why, a ternary expression minus one of the operators turns into an infix operator. In this particular case, there is another minor syntactic problem, but who cares...

  • Sgt. Preston (unregistered) in reply to Anonymous
    Anonymous:
    It's been a while since I've worked with Java, so I may be off here, but if I recall correctly, Java will throw a NPE when you call an instance method on a null object. Which means that second snippet is worse than pointless, it's completely broken.
    It's been a while for me too, but I believe you are correct about calling an instance method on a null object. To avoid that problem without cluttering up your code with a lot of null checks, simply call the equals() method on your zero-length string literal like this: 
    if ("".equals(reportGroup)) {
}

    A zero-length string literal is never null.

  • (cs) in reply to merreborn
    merreborn:
    NS:
    Can anyone explain why this is done?

    reportGroup.equals("")

    I know what it does (obviously), but I've picked up some maintenance work (C#/asp.net) and it is littered with them. Why does this happen so often? Is it in some example code somewhere that every new programmer reads?

    NS

    The first thing you learn in Java 101 is how to use == to compare two ints.

    Then, they ask you to compare two Strings, and you learn that == doesn't work on objects like you might expect, and you're taught to use String.equals() to compare strings.

    Now, using this basic knowledge, you need to test a string to see if it's empty. Logically, you use String.equals("") -- it's the string comparator you're most familiar with.

    Using String.length > 0 would probably be better, but they don't teach you that on the first day of Java 101.

    Actually, assuming you don't use the String constructor like a good little developer, == will work just fine with String. If two strings are equal, they should reference the same object in the string pool.

    Of course then all it takes is one developer to use your method with a String that was create via myString = new String("") and everything breaks.

  • (cs) in reply to Sgt. Preston
    Sgt. Preston:
    Anonymous:
    It's been a while since I've worked with Java, so I may be off here, but if I recall correctly, Java will throw a NPE when you call an instance method on a null object. Which means that second snippet is worse than pointless, it's completely broken.
    It's been a while for me too, but I believe you are correct about calling an instance method on a null object. To avoid that problem without cluttering up your code with a lot of null checks, simply call the equals() method on your zero-length string literal like this: 
    if ("".equals(reportGroup)) {
}

    A zero-length string literal is never null.

    Unless you also want it to evaluate to true when the String is null (which would be the case here if what they meant to say is: 

    if ((reportGroup == null) || (reportGroup.equals(""))) {

  • (cs)

    On the second code snippet:

    Could this have been caused by a code-merge of a version control system (e.g. merging a branch back into trunk for whatever reason) ? I mean, I haven't actually had something like that happening to me before .... but AFAIK it is not out of the realm of the possible.

  • (cs) in reply to nwbrown
    nwbrown:
    Actually, assuming you don't use the String constructor like a good little developer, == will work just fine with String. If two strings are equal, they should reference the same object in the string pool.
    Wrong. The pool only holds literals, constants and Strings that have been created with the String.intern() method.
  • (cs) in reply to brazzy
    brazzy:
    nwbrown:
    Actually, assuming you don't use the String constructor like a good little developer, == will work just fine with String. If two strings are equal, they should reference the same object in the string pool.
    Wrong. The pool only holds literals, constants and Strings that have been created with the String.intern() method.
    Which should include all the Strings you are using, unless you really want millions of different objects that represent the same unmutable value. Yes, there are other ways to get out of the String pool, but I'm not going into every little nuance of the Java language here.
  • Dave (unregistered)

    I hate oracle club.... http://forums.worsethanfailure.com/forums/17/ShowForum.aspx

    wouldn't it be easier to learn how NULL works? Not how you want it to work.

  • Boatman (unregistered) in reply to nwbrown
    nwbrown:
    brazzy:
    nwbrown:
    Actually, assuming you don't use the String constructor like a good little developer, == will work just fine with String. If two strings are equal, they should reference the same object in the string pool.
    Wrong. The pool only holds literals, constants and Strings that have been created with the String.intern() method.
    Which should include all the Strings you are using, unless you really want millions of different objects that represent the same unmutable value. Yes, there are other ways to get out of the String pool, but I'm not going into every little nuance of the Java language here.

    Well, as far as i know it does not include any strings set at run-time which are usually those most in need of checking. On a slightly different note, I recall seeing this attempt of testing for empty strings in java/jsp:

    String str = getParameter("paramId"); if( str.equals(null) || str.equals("") ){ str = //remainder omitted }

    As you might guess, the null check is there in case the parameter is not sent at all by the posting jsp page while the empty string part is for testing if the user simply did not fill in the field in question. Needless to say, the person who wrote this beauty never actually bothered to test how his servlet handled a null posting of the parameter...

  • M. Hiemstra (unregistered)

    Unfornately there arent any real programmers here.

    String.equals is always really bad because String can be null and it would throw a null pointer exception. So String.equals("") is just plain bad programming. A real programmer uses "".equals(String). Since "" is always a string an not null, no null pointer exception is ever thrown.

Leave a comment on “Double Take”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article