So I've run into this situation a million times in my "learning career" and I've always found a long way around the issue so as not to risk throwing unnecessary exceptions..

Let's look at a simple example...

boolean IsEnabled (JPanel MyPanel) {
	return MyPanel.isEnabled();
}

Throws java.lang.NullPointerException if null is passed to the method.

So, I've learned to check if an object is null before checking with its methods.

boolean IsEnabled (JPanel MyPanel) {
	if (MyPanel == null) return false;
	else return MyPanel.isEnabled();
}

// OR

boolean IsEnabled (JPanel MyPanel) {
	return (MyPanel == null) ? false : MyPanel.isEnabled();
}

Both work just fine, because MyPanel.isEnabled() is only called if MyPanel is not null. It's a more efficient alternative to wrapping MyPanel.isEnabled() in a try-catch statement. No exception should ever be thrown in the above case. The second method is simple, as all is contained in a single line, but is there anything simpler?

Today I saw something like the following snippet on the Internet:

boolean IsEnabled (JPanel MyPanel) {
	return MyPanel != null && MyPanel.isEnabled();
}

It combines the null-check and the data-check on the same line, separated by a logical operator. In this example, the logic is AND. If MyPanel is null, the first part of the check returns false, and MyPanel.isEnabled() is not called and no exception is thrown, even though a NullPointerException should be thrown. I suppose the false before the && is reason enough for the processor not to bother checking with whatever is after the &&, am I right?

Switching the order of the check to MyPanel.isEnabled() && MyPanel != null results in the exception. I guess what I'm trying to confirm is, has the JVM always given precedence to the first argument in a logical operation, and will it always ignore successive arguments given the first is reason enough to "call it quits"? I try my best to keep things organized, and often I'd like to combine object checks into a single line at the beginning of a method call, just to be tidy. I think I've answered my own question by running the test above, but, should I feel safe in the future to combine null- and data-checks into a single logical statement without watching for exceptions? ;)

Correct, this sort of thing is known as short circuit evaluation.

it also happens under logical OR evaluation when the left-hand-side of the expression yields 'true', ie

if ( true || false )

The program knows that there is no need to evaluate the right-hand-side, since the result of the boolean expression is already known for certain.

As you see in the example you've found, this is sometimes used in subtle ways to perform checks before executing a statement - Which is not always a good idea IMHO, because it runs the chance of being accidentally changed to introduce weird bugs! For example

int n=0;
if ( n!=0 && 10/n == 2 )

if this check was improperly altered in this block of code, the program could crash

int n=0;
if ( 10/n == 2 && n!=0 )
    //Bad: Looming catastrophe!

&& and || use the short-circuit evaluation. To force the compiler to check both conditions, use & or |.

In fact & and | aren't strictly logical comparison operators at all.
They're logical mathematical operators. So instead of performing a comparison you're performing a mathematical operation if you use them, and evaluating the result of that operation.

This article has been dead for over six months. Start a new discussion instead.