Christopher Young is correct; the NPE (NullPointerException) is the most misunderstood exception of all, but it has definitely got to do with object references. Various ways to get an NPE:
Declare an object and forget to instantiate it (probably the commonest).
Mistakenly set an object to null.
Forgetting that null values are permissible (eg in a tree, or when closing a Reader). That is the one situation where if (x != null) . . . is appropriate.
Mistakenly passing null as a parameter.
Forgetting there are some methods (eg for getting members from the Queue interface) which permit null returns.
Losing a reference; I once did it by setting a field to transient and not reinitialising it after serialization.
Passing null to an operator (eg throw null).
Throwing an NPE somewhere (unusual).
There are bound to be more. In 99% of instances, sorting out an NPE means correcting an error in the code. Using try-catch or too many if (x != null) . . .s is liable to obscure the cause of the error.
Originally posted by Campbell Ritchie: Throwing an NPE somewhere (unusual).
Actually it's quite usual, for checking parameters. Sometimes you don't need the value at the time of calling the parameter, but it is stored and you use it in a later method. You don't want it failing at that time because it'll be harder to find.
In fact, there are 307 classes in the java and javax packages that explicitly throw a NPE.