I read the article that Campbell Ritchie posted, and I'm in agreement, for the most part, however, I'm torn because at the end it said
"If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception"
I'm not sure if I totally agree. Most of the built-in unchecked exceptions are checkable by code, and the client can recover, so that doesn't agree with the Java core language. When I teach this to people, I usually say if an exception can be caught through logic (i.e. preventable), it should be an unchecked exception, if it can't (i.e. unpreventable), it should be a checked exception (e.g. opening a file for reading, since the program is generally on a multi-user platform, it's impossible to determine if the file is there to read, someone may have moved it while your program is running, however, a nullpointer, or divisionbyzero, both of them can be prevented through logic). This is in agreement with the Java core.
If there is a completely unrecoverable problem, it should be an Error, not an Exception.
Just my 2 cents
Garrett