As seen in the previous post, we need to construct an instance of a user-defined exception; the Java runtime cannot detect and create instances of user-defined exceptions. Thus, a user-defined exception is handled at the place of its occurrence. But what if we want to centralize the entire exception handling, including the user-defined application-specific exceptions, as explained earlier?

In such a case, there has to be some mechanism of passing the exception to a caller. As seen earlier, the Java runtime takes care of this for the system-generated exceptions. For user-defined exceptions, Java provides the throw keyword, which allows the exception to be passed to its caller. The throw statement is not restricted to user-defined exceptions and can be used for both user-defined and system-generated exceptions.

The important point to notice here is that:

·   The throws clause declares that a method passes the exception generated during its execution to its caller whereas

·    The throw statement explicitly creates or obtains an Exception object and passes it to its caller.

Re-throwing Exceptions

An exception event handler that receives an exception object is allowed to throw the received exception object to its caller. This may be done after the exception handler either has processed the exception or has decided not to process it at all. The JLS syntax for this is

try {

} catch ( ExceptionType exceptionObjectName ) {
throw ( exceptionObjectName )

where exceptionObjectName for catch and throw is the same. 

Here is how this will be done in our code:

try {

       // some arithmetic operation
} catch (ArithmeticException e) {
      // e may be partially processed here
       throw (e);



The catch block partially processes the ArithmeticException object. It prints the message associated with the received exception object. After processing the exception object, it calls the throw method with exception object e as its parameter. The caller receives the exception object and may use it for further diagnosis.

Rather than throwing the received exception object, we may like to create our own exception object with a custom message and throw it to the caller. We have already seen how to do this by declaring our exception class. However, there is a better way, which is shown in the following code snippet:

try {
        // numerical processing code
} catch (ArithmeticException e) {
         Throwable ae = new ArithmeticException("Attempt to divide by zero");


 ·  The exception handler now creates an instance of the original exception type and sets a custom message in it. The original exception is then embedded into the new object by calling the initCause method.

·    Finally, the newly constructed object is thrown to the caller. The caller now has an exception object that contains a custom message created by the method in which an exception is generated, along with the cause of the exception.

·     To retrieve the custom message, the caller calls the getMessage method on the received exception object.

·   To get further information about the exception, the caller calls the getCause method on the exception object, as shown in the following code snippet:                       System.out.println(e.getMessage());                                 System.out.println(e.getCause().getMessage());

The first statement prints the custom message to the console, whereas the second one prints the original error message. The initCause and getCause methods were introduced as of J2SE 1.4.

The method of wrapping the original exception object into a custom object and throwing it to the caller is also sometimes called exception chaining. The exceptions are chained and passed to the caller.

  Modified On Dec-16-2017 07:37:02 AM
  1. Thanks samuel it is very informative related to exception handling in java.

Leave Comment