Where should you check for NullPointerExceptions

I was tempted to check for null the other day in a method and then I thought that you could really check for nulls in all of my methods. So I thought this must be a bad idea because otherwise it would be more common and what can you do if you find one.

I thought about catching the null -- no if someone has passed in null it's their fault

should I return null value - I don't think passing back a null value is good form

perhaps I should just throw a NullPointerException, yes good plan, so I thought I would just leave the code and let the JVM keep throwing it up until it found somewhere.

I was slightly confused and there isn't much information about it, I have blogged about this issue before, where I chose the wrong idea and caught the null and returned a value. This actually caused another bug until I went back and threw a null or actually didn't do anything and changed the code that called it. Initially I decided to catch the null and pass back a zero. After some good comments I changed my thinking on this, many thanks to the people who commented on that blog entry.

The issue of catching a null did result in a much sneaker bug being put in because I caught a null and returned a zero in a removing fraction function (dodgy I know) but the zero's caused a map with length and height of zero to be drawn. Basically if you passed in zero we didn't want any maps to be drawn later on, so instead of catching the error I sort of hid it, which was bad bad bad.

It does bring up a tricky question where do you decide to catch this null.

Anyway this blog has a decent stab at working out the logic

"Step one is usually removing unrequired optionality; replacing pointers that can't be null with references and removing any, now redundant, checking code. As soon as see a function that takes a pointer and immediately checks it for null you know you can remove the 1 or 0 optionality of a pointer and replace it with the certainty of a reference. Like retrofitting const correctness; once you do it in one place, you can chase back up the call stack until you find the point where the value really is optional. Things like this are simple to do but they vitally important in keeping code under control and understandable. By reducing the amount of things you have to question when you read a piece of code you can make the code easier to understand; no need to worry if this pointer can be null if you're given a reference that can't ever be. "

I like the point the quote is making that basically there is some point higher up in the code where the object/class might be null and this is the place to check it and the lower more simple code just has to assume that in most examples you are going to put in a valid object.

It certainly has a catch 22 type feeling to it and I can't seem to find to much information or best practices for it.