• Xarium (unregistered) in reply to [twisti]

    RE: twisti

    class Warning { void showWarning( JFrame, string, string ); void showWarning( MyClass, string, string ); }

    Try calling the overloaded method with "null" as the first parameter - without using a local variable.

    P.S I'm not interested in a debate about the "quality" of the above code, it is simply a contextual reason for why casting null is perfectly valid.

  • an actual coder (unregistered) in reply to Andy

    Argh! NO no no no no no. For your information: you are completely mad. Please remove the part of your brain that told you to check this for null and then review your threading skills.

  • troels (unregistered) in reply to Volmarias

    You lucky bastard.

  • jjonphl (unregistered)

    Unbelievable.

  • (cs)

    They are amateurs. I have a much better one. field is a pointer btw.

    if (field == 0) { // bad format for the buffer } long size = field->getLong();

  • Tom (unregistered) in reply to [twisti]

    Casting can be necessary in case of an oveloaded function. Otherwise it causes a type conflict error.

  • Matthew J. (unregistered) in reply to [twisti]

    The casting here may actually be necessary if Warning had two or more methods with the nearly the same signatures. For example, say there's the methods warning(JFrame, String, String) and warning(JComponent, String, String). In this case, the compiler wouldn't know which method should be called when it sees Warning.showWarning(null, title, msg). Thus, the casting is necessary for the program to even compile.

  • Rydier (unregistered) in reply to StickyWidget

    I'd argue the point that "everything still works", when in the best case you'd have an error message that, if it worked at all, did nothing but tell you that null is null...

  • TheReaper (unregistered) in reply to StickyWidget

    Actually, the problem exists in both snippets, since "this.equals(null)" will also throw a NullReferenceException if "this" is null.

  • gallier2 (unregistered)

    Like my collegue who wrote this in plain old C (don't get offended by the this pointer, it's not the WTF). RawYear is an int

    this->rw_oldcrit.RawYear=0;                                                
this->rw_crit.RawYear&&(this->rw_oldcrit.RawYear=this->rw_crit.RawYear);

    A quite complicated way of doing

    this->rw_oldcrit.RawYear =                                              this->rw_crit.RawYear;

    His code is full of obfuscations like that (and I chose this one because it is one of the simpler one), I hate him.

  • suscript (unregistered) in reply to [twisti]
    [twisti]:
    One of the best parts of the article got completely ignore by all commenters!

    Warning.showWarning((JFrame) null, title, msg);

    He's casting null into a JFrame! It really makes you wonder what that would do if it would actually work ... create a special null that isn't actually null but an empty JFrame ?

    It might take multiply items as the first param.

  • sebster (unregistered) in reply to [twisti]

    Actually, casting null is probably used to choose between different overloaded versions of the showWarning method. The compiler will complain that the call is ambiguous if you just supply null without the cast.

  • mike (unregistered) in reply to Volmarias

    you must be new to this whole programming then.

  • Nullatastic (unregistered)

    You have to love this line,

    if (this.equals(null))

    hilarious, I might even promote it to my bouncing word screensaver.

  • James (unregistered)

    Both of these fail in interesting, and subtle ways:

    1. you don't need to declare a RuntimeException throwing a runtime exception on a null is unusual - you would expect a nullpointerexception dereferencing the null will throw a nullpointerexception, which is a RuntimeException

    2. 'this' can never be null in java if it did happen (which it cannot) - calling .equals() on it will throw an exception. casting a hard-coded null to a type is only needed if you have overloaded methods with almost the same types. in any case - when "this" is null (which it can't be) either route through the code would have the same effect.

  • Anonymoose (unregistered)

    Of course, the thing that I find disturbing is that a "supposed" OOP language like JAVA has a constant that is NOT a member of a class.

    Specifically, null should be in class null, and should be the only member OF that class. Retrieving the class of something should itself NEVER fail.

    And, yes, I may make that exact error (and I would blame it on JAVA, for its braindead design).

    A nMoose.

  • Chris (unregistered) in reply to [twisti]

    Casting null to JFrame may be necessary, depending on the implementation of Warning.showWarning. If there are multiple overloads that differ only in the type of the first parameter, then the cast resolves an ambiguity that would cause a compiler error.

  • Gabe (gabebear) (unregistered) in reply to Andy

    It's much much worse than that. You can't call a function on a null reference... so the posted code will never work. Check out http://forum.java.sun.com/thread.jspa?threadID=284362&messageID=1111440 for some more fun in the same vein.

  • Problem Child (unregistered) in reply to ObiWayneKenobi

    A senior developer is generally someone dumb enough to work for a company that gives out job titles in lieu of pay rises.

    Gather ye peasecods while ye may - or else!

  • (cs) in reply to James
    James:
    Both of these fail in interesting, and subtle ways:

    1. you don't need to declare a RuntimeException throwing a runtime exception on a null is unusual - you would expect a nullpointerexception dereferencing the null will throw a nullpointerexception, which is a RuntimeException

    2. 'this' can never be null in java if it did happen (which it cannot) - calling .equals() on it will throw an exception. casting a hard-coded null to a type is only needed if you have overloaded methods with almost the same types. in any case - when "this" is null (which it can't be) either route through the code would have the same effect.

    You're right: those are both interesting and subtle.

    Sheesh.

    But at least this comment is preferable to the 25% of respondents pointing out that Java has overloaded methods. What, you mean it's a real language now? I look forwards to a proper implementation of generics that isn't just syntactic sugar.

  • (cs)

    I was looking over the second fragment, and it was like a delayed-reaction WTF. First, I noticed that the code blocks were exactly the same. Then, the real WTF of that code block hit me...

    if (this.equals(null))

    ::facepalm::

    It makes me wonder, however, if the first block would be flagged as unreachable code, because a NullPointerException would be thrown before that block would ever execute. Either that, or this.equals(null) can return true when this is not null, which would be a whole different level of WTF.

  • Matthew Wakeling (unregistered) in reply to [twisti]

    Casting null to a class is quite valid when calling a method. It allows the compiler to decide which method is being called. For example, there could be a method Warning.showWarning(Turnip, String, String). If so, and null wasn't cast, then the compiler would give an error about an ambiguous method call. One of the consequences of Java allowing multiple methods of the same name.

  • JC (unregistered) in reply to [twisti]

    If the method is heavily overloaded, casting null disambiguates the method for the compiler.

    For example:

    class Util { static void foo(String s) {...} static void foo(Integer o) {...} }

    If you call: Util.foo(null); //Ambiguous Util.foo((String)null) //Ok

  • Doc Brown (unregistered)

    I wonder how noone mentioned a somewhat similar antipattern in SQL variants, where developers jovially try to check "x=null" and "x!=null" and see it not doing quite what is expected. (Because any comparison with null returns null, except for "x IS null" and "x IS NOT null", which actually can be true or false.)

  • Ben (unregistered) in reply to [twisti]

    This is actually ok, and has valid uses..

    http://stackoverflow.com/questions/358079/casting-null-as-an-object

  • Jonathan Gilbert (unregistered) in reply to endasil
    endasil:
    Andy:
    That said, the check done in that first one is totally broken anyway, as it's dereferencing the null when trying to generate the exception.

    Actually, it does exactly what it's supposed to do. It throws a RuntimeException if o is null. Granted, it does so a great deal sooner than the explicit "throw" statement is reached, and doesn't contain any of the error message. And as has been said, the method signature includes a throws clause which is in this case pointless.

    But other than that, this code is perfectly safe. It could be rewritten simply as this:

    public void failIfNull(Object o) {
  o.toString();
}

    Technically not quite right. The "toString" method might be overloaded with something complex that could potentially fail independently of 'o' being null (or, worse, if the programmers involved are especially poor, have side-effects). However, if you boil it down to the first method call that actually runs in the function, you can simplify it to this:

    public void failIfNull(Object o)
{
  o.getClass();
}

Leave a comment on “A Null Understanding”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article