This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NullPointerException stops execution...

 
jay vas
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Jon Parise
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Sheriff
Posts: 48445
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    Jon Parise
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I agree with all your points Campbell.

    This is all good advice. The key is figuring out which object is null.
     
    Ernest Friedman-Hill
    author and iconoclast
    Marshal
    Pie
    Posts: 24208
    35
    Chrome Eclipse IDE Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:

     
    Mike Simmons
    Ranch Hand
    Posts: 3028
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Also synchronized(foo) would throw a NullPointerException.
     
    Campbell Ritchie
    Sheriff
    Posts: 48445
    56
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    . . . and I once tried to throw a null Exception, which produced a NPE.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic