Comment On A Null Understanding

if (this != null)

{

  ...

}

this.equals(null)

Hmm... the bigger issue, besides the shit code, is that the first one was written by a "senior developer". I would imagine a senior developer to know better, but then again this IS the Daily WTF, and most of the snippets/evil stuff here was written by "senior" developers.

method foo.bar()

  # do some processing

  if a isnt null

  then

    return a

  endif 

endmethod

method foo.bar()

  # do some processing

  if a isnt null

  then

    return a

  else

    return null

  endif 

endmethod

method foo.bar()

  # do some processing

  return a

endmethod

Sunstorm:

I'm not sure if I understand the WTFiness of the first one, since I'm not versed in how Java treats nulls. Is the WTF that Java would already throw an exception on it's own if you access a null?

Sunstorm:

I'm not sure if I understand the WTFiness of the first one, since I'm not versed in how Java treats nulls. Is the WTF that Java would already throw an exception on it's own if you access a null?

anon:

Is this a Java thing? I get you'd never design a system this way yourself, but what if they are interacting with a third party library in C++ that returns pointers? One would expect that you'd check to see that a pointer returned isn't NULL before it's dereferenced.

If the fact that the pointer is NULL is a failing case anyway, then failIfNull() collapses four physical lines of code down to one, and eliminates a layer of indirection. If you're making a dozen calls in a row into this library then failIfNull() eliminates a lot of redundant code.

anon:

Is this a Java thing? I get you'd never design a system this way yourself, but what if they are interacting with a third party library in C++ that returns pointers? One would expect that you'd check to see that a pointer returned isn't NULL before it's dereferenced.

If the fact that the pointer is NULL is a failing case anyway, then failIfNull() collapses four physical lines of code down to one, and eliminates a layer of indirection. If you're making a dozen calls in a row into this library then failIfNull() eliminates a lot of redundant code.

[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 ?

[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 ?

mallard:

Anyone else noticed that the forums (incl. Sidebar) are broken?

anonym:

Yes, both snippets invoke methods on null objects. You cannot invoke a method in a null object, java throws a NullPointerException :)

pscs:

[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 ?

I don't know enough about 'showWarning', but in the Windows SDK, 'MessageBox' is passed a window handle as the first parameter if you want the MessageBox to be the child of another window, or you pass 'NULL' if you want it not to be a child window of anything.

I'd guess that it's possibly the same here.

Chris:

As for the second one, it's utterly redundant. You cannot call a method on yourself until you're constructed. Even calling a method on itself from the objects constructor wont result in "this" being null.

Andy:

pscs:

[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 ?

I don't know enough about 'showWarning', but in the Windows SDK, 'MessageBox' is passed a window handle as the first parameter if you want the MessageBox to be the child of another window, or you pass 'NULL' if you want it not to be a child window of anything.

I'd guess that it's possibly the same here.

It's probably to remove ambiguity. Warning.showWarning probably has multiple signatures, with the only difference being the type of the first argument. When you pass 'null' explicitly (as opposed to a variable that's set to null) the compiler doesn't know the type, so it can't determine which version of the method to call. By casting it to a JFrame the compiler knows which showWarning() method to call.

pscs:

Chris:

As for the second one, it's utterly redundant. You cannot call a method on yourself until you're constructed. Even calling a method on itself from the objects constructor wont result in "this" being null.

Ah, but it ain't necessarily so (at least in C++)

---------
#include <stdio.h>

class myObject
{
public:
void Print(void)
{
printf("0x%08lx\n", this);
}
};

myObject *foo()
{
return NULL;
}

int main()
{
myObject *p = foo();
p->Print();
}
----------

Here the 'Print' object will be called on an object whose 'this' pointer is NULL, so it'll print out '0x00000000'

djork:

I have come across LOTS of code in my project that follows the I-Hope-I'm-Not-Null pattern:

if (this != null)

{

  ...

}

krupa:

I can't tell if you're serious about this or not. foo() returns NULL, so p is null, so p->Print() is a seg. fault.

krupa:

krupa:

I can't tell if you're serious about this or not. foo() returns NULL, so p is null, so p->Print() is a seg. fault.

OOPS, I take that back. That actually does work.

String name = retrieveName(object);

if (name == null) {

   log.warn("object name was null");

} else {

   ...

}



...



String retrieveName(MyObjectWrapper object) {

   String retVal = object.getName();

   if (retVal == null) {

      log.warn("object retrieveName was null");

   }

}



...



class MyObject {

   String getName() {

      if (this.name == null) {

         log.warn("getName returned null");

      }

      return this.name;

   }

}

dkf:

krupa:

krupa:

I can't tell if you're serious about this or not. foo() returns NULL, so p is null, so p->Print() is a seg. fault.

OOPS, I take that back. That actually does work.

But it wouldn't work if the method was virtual. In Java, all non-static methods are virtual (i.e. resolved according to the real object type).

The fact that is this works in C++ is today's Real WTF?!

pscs:

Chris:

As for the second one, it's utterly redundant. You cannot call a method on yourself until you're constructed. Even calling a method on itself from the objects constructor wont result in "this" being null.

Ah, but it ain't necessarily so (at least in C++)

---------
#include <stdio.h>

class myObject
{
public:
void Print(void)
{
printf("0x%08lx\n", this);
}
};

myObject *foo()
{
return NULL;
}

int main()
{
myObject *p = foo();
p->Print();
}
----------

Here the 'Print' object will be called on an object whose 'this' pointer is NULL, so it'll print out '0x00000000'

krupa:

pscs:

Ah, but it ain't necessarily so (at least in C++)

---------
#include <stdio.h>

class myObject
{
public:
void Print(void)
{
printf("0x%08lx\n", this);
}
};

myObject *foo()
{
return NULL;
}

int main()
{
myObject *p = foo();
p->Print();
}
----------

Here the 'Print' object will be called on an object whose 'this' pointer is NULL, so it'll print out '0x00000000'

I can't tell if you're serious about this or not. foo() returns NULL, so p is null, so p->Print() is a seg. fault.

delete this;

Andy:

So, strangely enough, I've seen places where that was needed.

In a C++ DLL I was working on there was this weird race condition happening during the unloading of the DLL, and one of the methods would occasionally crash. When walking through it with the debugger I found that the crash happened because `this` was equal to NULL. I never managed to find the root cause of the problem, but just putting

`if(this == NULL) { return; }

at the top of the function fixed the crash. Since it was happening when the DLL was being unloaded and the results of that function weren't really important anymore we decided it wasn't worth killing ourselves trying to find the root cause anymore.

Fortunately, my current project is to rewrite that entire DLL (mainly triggered by Vista incompatibilities. Thanks Vista!), so hopefully I'll be able to avoid that this time. :)

[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 ?

Warning.showWarning(JButton, String, String)

Warning.showWarning(JFrame, String, String)

        Object o = new Object();

        System.out.println(o.getClass().getName());

        o = new String("hello");

        System.out.println(o.getClass().getName());

java.lang.Object

java.lang.String

StickyWidget:

Luckily for this joker, a NullPointerException is a subtype of RuntimeException, so everything still works. If he had set it to throw some other kind of exception, he'd be in trouble, as the NullPointerException would crash the whole thing.

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.