What to throw, Checked or Unchecked Exceptions?

If you throw a checked exception (and don't catch it), you will need to declare the exception in your method's throws clause. Client programmers who wish to call your method will then need to either catch and handle the exception within the body of their methods, or declare the exception in the throws clause of their methods. Making an exception checked forces client programmers to deal with the possibility that the exception will be thrown.

If you throw an unchecked exception, client programmers can decide whether to catch or disregard the exception, just as with checked exceptions. With an unchecked exception, however, the compiler doesn't force client programmers either to catch the exception or declare it in a throws clause. In fact, client programmers may not even know that the exception could be thrown. Either way, client programmers are less likely to think about what they should do in the event of an unchecked exception than they are in the case of an checked exception.

The simple guideline is:
If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.

Note that when String.charAt(int index) receives a bad input, it doesn't throw RuntimeException or even IllegalArgumentException. It throws StringIndexOutOfBoundsException. The type name indicates that the problem was a string index, and the program can query the object to find out what the bad index was.

Here is a collection of the exception guidelines put forth by an article:

• If your method encounters an abnormal condition that it can't handle, it should throw an exception.
• Avoid using exceptions to indicate conditions that can reasonably be expected as part of the normal functioning of the method.
• If your method discovers that the client has breached its contractual obligations (for example, by passing in bad input data), throw an unchecked exception.
• If your method is unable to fulfill its contract, throw either a checked or unchecked exception.
• If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.
• Define or choose an already existing exception class for each kind of abnormal condition that may cause your method to throw an exception.

Here's a summary of the mechanical aspects of exceptions:

Runtime exceptions

• A method signature does not need to declare runtime exceptions
• A caller to a method that throws a runtime exception is not forced to catch the runtime exception
• Runtime exceptions extend from RuntimeException or Error

Checked exceptions

• A method must declare each checked exception it throws
• A caller to a method that throws a checked exception must either catch the exception or throw the exception itself
• Checked exceptions extend from Exception