Don't touch the null, it may explode



  • This one is a double java related wtf that enligthened my day, from the tomcat mailing list. For those not knowing, this mailing list is related to a java web application server, a domain where you can expect people to have a bit of programming background. But sometimes you get a bit of fun...

    I know that this question of mine has been asked/answered in this group, but I was wondering how do I go about checking for a null value?

    Common sense would say to use a if (o == null). Pretty basic coding. But someone went with a clever solution. He was clearly joking at the question and answered this:

    try
    {
    Image logo=null;
    logo = Toolkit.getDefaultToolkit().getImage("images/splash.png");
    }
    catch(NullPointerException excp)
    {
    log.debug("NullPointerException thrown while retreiving image images/splash.png");
    System.out.println("NullPointerException thrown while retrieving images/splash.png");
    }
    Opportunity to use a catch statement for a NPE there is left as exercise. The main problem is that the guy was not making a fool of the original request. He sent us this email, a bit later:
     the instant you execute code where a variable is NULL you will throw NullPointerException if you want robust code you are better off wrapping in try catch block as in
    try
    {
    if( in == null) System.out.println("This statement will never be executed as NullPointerException will be thrown");
    }
    catch(NullPointerException npe)
    {
    System.out.println("variable in has thrown NullPointerException so something about that here");
    }
     

    This guy was really thinking that null references could somehow explode the instant you touch it and was giving us advices to protect every piece of code from the devil NullPointerException by using try/catch every time we want to test a variable. And of course, never do a if (o!=null) /*safe to use o*/ as the will touch the dangerous null and will explode :)

     



     



  • Anyone with any coding experience knows that a null will explode if you even look at it funny.  That's why we mandated the use of Object Null.  This way, we can safely set and compare things to Null, without having to worry that our complier will burst into flames or NullPointerExceptions will show their ugly heads when we make gross coding errors.



  • Clearly someone in dire need of a bool is_really_null_13(Object o).



  • Well, it won't actually explode. The NULL is of course cyberspace's version of real spaces Black Hole.

    Touching it will cause you to spin ever more rapidly until you disappear up your own backside. 



  • I never knew that Java's null is actually an instance of the HappyFunBall class.



  • I have to give this one a good rating.  My jaw actually dropped.  The only thing worse than an idiot, is one who honestly thinks he's helping the idiots.



  • Just make sure you dont try to reference the null value inside the catch block, that will not only explode on you, but it will also send viruses to everyone in your mailing list, tape your dog to the ceiling, and overfeed your pet fish until they swell up and burst.



  • The Ten Commandments for C Programmers


    2 Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

    Clearly the holy scriptures were mis-transcribed here, as the words should have been ``null pointer'', to minimize confusion between the concept of null pointers and the macro NULL (of which more anon). Otherwise, the meaning is plain. A null pointer points to regions filled with dragons, demons, core dumps, and numberless other foul creatures, all of which delight in frolicing in thy program if thou disturb their sleep. A null pointer doth not point to a 0 of any type, despite some blasphemous old code which impiously assumes this.



  • How can anyone be so stupid as to think that a null pointer would explode i you touch it? Of course it will not explode, it will implode.



  • Create a new project-wide superclass from which every class in the project will be derived.

    public class ProjectObject extends Object {

      public boolean isNull() {

         return (this == null);

      }

    }

    Then it's simple!  Just create a subclass for each kind of object you use, for instance:

    class ProjectImage extends Image, ProjectObject { }

    using multiple inheritance like we used to do in C++, remember?

    ProjectImage logo = (ProjectImage) Toolkit.getDefaultToolkit().getImage("images/splash.png");

    if (logo.isNull()) {System.out.println("File not found");}

     



  • ProjectImage logo = ...
    if (logo.isNull()) ...

    somehow I don't think that'll work



  • [quote user="Astaedus"]

    ProjectImage logo = ...
    if (logo.isNull()) ...

    somehow I don't think that'll work

    [/quote]

    You're right.  it has to be a static function:

      static public boolean isNull() {

          return (this == null);

      }



  • [quote user="fluffy777"]The Ten Commandments for C Programmers


    2 Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

    Clearly the holy scriptures were mis-transcribed here, as the words should have been ``null pointer'', to minimize confusion between the concept of null pointers and the macro NULL (of which more anon). Otherwise, the meaning is plain. A null pointer points to regions filled with dragons, demons, core dumps, and numberless other foul creatures, all of which delight in frolicing in thy program if thou disturb their sleep. A null pointer doth not point to a 0 of any type, despite some blasphemous old code which impiously assumes this.

    [/quote]

    Given how badly that hosed formatting once, I'm wondering what happens if I quote it...



  • [quote user="newfweiler"]

    public class ProjectObject extends Object {

      public boolean isNull() {

         return (this == null);

      }

    }

    [/quote]

    This approach doesn't solve the problem. You're still potentially referencing a null instance. What if this actually is null?

    The approach I recommend is to extend java.lang.System, adding a method to wrap all instantiation in a safe way which avoids nulls altogether like this:

    public static final Object instantiateInASafeWayWhichAvoidsNullsAltogether(Object o) {
       return new Object();
    }

    That way, this:

    Image image = Toolkit.getDefaultToolkit().getDefaultToolkit().getDefaultToolkit().createImage(new byte[2]);
    if (image == null) {
      System.err.println("This is the end of space-time as we know it");
    }

     becomes this:

    Image image = (Image)ProjectSystem.instantiateInASafeWayWhichAvoidsNullsAltogether(Toolkit.getDefaultToolkit().getDefaultToolkit().getDefaultToolkit().createImage(new byte[2]));
    if (image == null) {
      System.err.println("This will never happen.");
    }

     

    Class Caste xceptions are much safer than null. Also easier for outsourced developers to understand.



  • [quote user="Guffa"]How can anyone be so stupid as to think that a null pointer would explode i you touch it? Of course it will not explode, it will implode.
    [/quote]

    I don't think it implodes either, it just returns FILE_NOT_FOUND.


Log in to reply