NullPointerException stops execution...

Hi guys . I have a program that periodically throws a null pointer exception which is non critical. For some reason, however, it stops execution. I tried putting it in a try catch block and it STILL stops execution.
I have 2 questions ...

1) Why do Null Pointer Exceptions stop execution ?

2) Why do they still stop execution even when in try catch blocks ?

Other exceptions dont seem to act this way...

What do you do with the exception when you catch it?

Could you post the Try Catch block and the offending lines of code?

Also, think about this question:

How can you re-write whatever function/code is throwing this exception to make it stop? Usually a NullPointerException is an error in the program(not always) and there is another way to write it to get rid of it.

Sometimes it is also helpful to add:

if(obj != null){

obj.doSomething();

}

Generally I don't think a NullPointerException should stop execution if it is caught. Usually it is only a problem if it isn't caught. Try printing something in the catch block to make sure the exception is really happening where you think it is happening.

Ex:

Try{

some code
}
Catch(NullPointerException npex){
System.out.println("Catch NPEX! in function<insert name>");
npex.printStackTrace();
}

It could be that it is thrown elsewhere, and you just think you are catching it.

Disagree. You ought not even try to catch an NPE in 99% of cases. And the if(x!=null) test should only be applied where a null value is a legitimiate possibility, eg

In a tree data structure; every time you add a value you add a node with at least two null values.

In a try-finally for opening a Reader; when you try to close the Reader there might have been an Exception and the Reader might be null.

Some methods have a null return value if they fail to find a value, eg the poll() methods of a Queue.

Otherwise in most instances too many if(x!=null)s and catching NPEs simply obscures errors.

Go and look through all the fields in your class, and make sure they are all initialised in the constructors.
Go and look at all the method invocations and make sure you aren't passing null by mistake.
Make sure you haven't mistakenly set an object to null.
Make sure you aren't mistakenly returning null from some method or other.

If that doesn't help, go to one line before wherever the NPE occurs (let it propagate and get a stack trace), then put in a line which prints every object you are using calling or invoking. Something like this
See which of them prints out as "null." The hard part about bugs is not correcting them, but finding them. If you get a "null" print, then you know which object to follow and see why it's not initialised.

I agree with all your points Campbell.

This is all good advice. The key is figuring out which object is null.

Originally posted by Jon Parise:
The key is figuring out which object is null.

That's easy! The stack trace of the exception tells you the exact line of code where the error occurs. Something on that line that appears to the left of a dot (".") or bracket ("[") is null. From there's it's generally not to hard.

Originally posted by Ernest Friedman-Hill:

That's easy! The stack trace of the exception tells you the exact line of code where the error occurs. Something on that line that appears to the left of a dot (".") or bracket ("[") is null. From there's it's generally not to hard.

There is a another obscure cause: auto-unboxing can cause a NPE, too:

Also synchronized(foo) would throw a NullPointerException.

. . . and I once tried to throw a null Exception, which produced a NPE.