The parameters given to the method are not well defined (i.e. are wrong / null where they must not be)
The " constellation " of the parameter values are not expected in the given way by the method (because if parameter "a" has a certain value, "b" must not be of another certain value)
The caller of the method simply calls it in an improper way (i.e. the environmental conditions are not correct, needed resources are not allocated yet etc.)
The method allocates external resources (i.e. open connections, file handles etc.) and does not free them (thus leading to an invalid internal state of the program, the operating system or other components like databases)
The method relies on external resources (i.e. file system, database etc.) which are not available at the moment they are needed
Checked exceptions: Exceptions that inherit from the Exception class are checked exceptions. Client code has to handle the checked exceptions thrown by the API, either in a catch clause or by forwarding it outward with the throws clause.
Unchecked exceptions: RuntimeException also extends from Exception. However, all of the exceptions that inherit from RuntimeException get special treatment. There is no requirement for the client code to deal with them, and hence they are called unchecked exceptions.
Errors (members of the Error family) are usually thrown for more serious problems, such as OutOfMemoryError, that may not be so easy to handle. In general, code you write should throw only exceptions, not errors. Errors are usually thrown by the methods of the Java API, or by the Java virtual machine itself.
Errors usually signal abnormal conditions that you wouldn't want a program to handle. Problems with linking, such as NoClassDefFoundError, or memory, such as StackOverflowError, could happen just about anywhere in a program. In the rare cases in which they happen, it is usually reasonable that the thread terminate.
Java Language Specification advises against throwing errors. It is intended that errors be thrown only by the Java runtime.
"What action can the client code take when the exception occurs?"
Make it a checked exception Client code will take some useful recovery action based on information in exception Make it an unchecked exception Client code cannot do anything Exception type Client's reaction when exception happens
If you are throwing an exception to indicate an improper use of your class, you are signalling a software bug. The class of exception you throw probably should descend from RuntimeException, which will make it unchecked.
If you are throwing an exception to indicate not a software bug but an abnormal condition that client programmers should deal with every time they use your method, your exception should be checked .
If you feel that a method doesn't know how to handle a particular error, you can throw an exception from the method and let someone else deal with it. If you throw a "checked" exception, you enlist the help of the Java compiler to force client programmers to deal with the potential exception, either by catching it or declaring it in the throws clause of their methods.
Another Approach to decide whether to use checked exception or unchecked.
One design approach often discussed in the context of object-oriented programming is the Design by Contract approach. This approach to software design says that a method represents a contract between the client (the caller of the method) and the class that declares the method. The contract includes preconditions that the client must fulfil and postconditions that the method itself must fulfil.
What information does java.lang.Exception contain
The type of exception -- the exception class
Where the exception occurred -- the stack trace
Context and explanatory information -- the error message, and other state information
An expected condition demanding an alternative response from a method that can be expressed in terms of the method's intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them.
An unplanned condition that prevents a method from achieving its intended purpose that cannot be described without reference to the method's internal implementation.
Mapping to java exception An unchecked exception A checked exception Best Mapping Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers Alternative return modes Examples The people who need to fix the problem The upstream code that invokes the method Who cares about it Never rarely Is expected to happen A nasty surprise A part of the design Is considered to be Fault Contingency Condition
Goals of a successful fault handling framework