Exception Handling with Examples

What is an exception?

Exception is an event during the execution of a program that disrupts the normal flow and prevents the program from doing what it is expected to do e.g., a program tries to write to a log file but the file cannot be opened.

Two Pass vs One Pass: Net Runtime has Two Pass exception handling implementation. Two Pass means the runtime first traverses through entire call stack to find a handler, and after either finding a handler or determining that its an unhandled exception, it runs all the finally blocks in the call stack. JVM on the other hand runs finally block in a method if a handler is not found in that method and then it moves up the call stack. See  and  for detailed explanation.

Asynchronous Execution

public class AsyncRun implements Runnable {
  @Override
  public void run() {
        // TODO Auto-generated method stub
    System.out.println("AsyncRun.run on thread " + Thread.currentThread().getId());
    throw new ArithmeticException();
  }    
}

public static void main( String[] args ) {
  try {
    Thread t = new Thread(new AsyncRun());
    t.start();
    System.out.println( "main on thread " + Thread.currentThread().getId());
    throw new NullPointerException();
  }
  catch(Exception ex)
  {
    System.out.println(ex.getClass().getName() + " handled");
  }
}

main on thread 1
AsyncRun.run on thread 15
java.lang.NullPointerException handled
Exception in thread "Thread-0" java.lang.ArithmeticException
        at exceptionhandling.AsyncRun.run(AsyncRun.java:13)
        at java.base/java.lang.Thread.run(Thread.java:835)

NullPointerException thrown by the main method is handled by the try-catch in main method, but the exception in AsyncRun.run method is treated as an unhandled exception because JVM could not find a handler in the call stack on the thread running AsyncRun.run. AsyncRun.run is the first method to be called on the thread so the call stack ends there, so the try-catch in the main method won't apply to AsyncRun.run.

Alternative to Exceptions

Why handle exceptions?

1. Prevent crashes: Unhandled exception may result in application crash. So even to prevent a crash an application needs to handle exceptions.
2. Alternate flow: In some cases, there may be a need to change the flow of the program in the event of an error condition e.g., in online shopping portal, when a payment API request throws exception, user journey would require the application to handle it and take the user back to the basket page so that user can initiate the payment again.
3. Logging: Logging is required for troubleshooting.

Where to handle exceptions?

Where to handle exception is very important and broadly there are two types of places where exceptions should be handled:

1. All Entry Points in to the program \ application to prevent crashes. As we have seen above when an exception reaches the runtime or framework, it may cause a crash. Entry Points can be one or more like:

1. main method
2. Event handlers in a UI application - SPA or desktop application
3. Public methods on a Controller in an MVC application
4. Starting method of a background thread

Exception Handling by Application Types

Library

Libraries do not control the flow of program. Functions of libraries are called by the main program with some input and they return some output or provide some behavior e.g, as shown in diagram below, RecommendationEngine executable uses libraries for logging, data access, etc. to perform its job but the flow of program is controlled by the executable only.

Therefore, code in a library should not suppress exceptions because that would prevent the calling application from fulfilling alternate flow and logging requirements - it can catch exceptions and rethrow or provide expected output by catching exceptions.

There can be scenarios where a library needs to handle exceptions like explained in the following case, but it should not suppress the exceptions e.g., continuing with the above example, let's say the data can come from MySQL or MongoDB so the DataAccess library itself relies on other libraries. But to make the RecommendataionEngine depend only on the DataAccess library, the DataAccess library can handle exception from MySQL and MongoDB and then throw its own exception. Re-throwing would ensure that the RecommendationEngine gets a chance to decide what to do with the exception.

API

As in the case of Library, the caller of API (the RecommendationEgine) should handle the exception, but because of the change in the nature of invocation of Data Access APIs, exceptions need to be handled by API also for the following reasons:

• Data Access API as Library: in this case, when an exception occurs, the caller (RecommendationEngine) is in same process and the runtime lets it handle the exception - also the exception object would provide details about what happened so that caller can take appropriate action.
• Data Access API as REST API: here the caller (RecommendationEngine) is not in the same process. Caller is expecting a valid HTTP response from the REST API. So if the API itself doesn't handle exception, the framework (ASP.Net MVC, Spring MVC, etc.) has to handle it and return a valid HTTP response, which may not provide enough details to the caller about the error.
• So REST API itself should handle the exception and return a response that the caller can use that to determine that there was an error. In this case, the response (API Response Body) will have to carry error codes and the caller should perform actions based on error codes.
  

Framework

This is how it works:

• (a) Spring (framework) discovers controllers with @Controller annotation on a Class
• (b) DI container would initialize the classes (or load a plug-in) by calling their constructors
• (c) when an HTTP request for a matching URL is received, Spring MVC calls appropriate method on the plugin (object instantiated in (b)) and returns the response.

In the above diagram the calls from Spring to the application - marked with X - are vulnerable points as Spring cannot assume that the application would not throw exceptions, so it would handle exceptions e.g., if UserController.create method throws exception, Spring MVC would handle it and trigger alternate flow to return an appropriate HTTP response indicating error.

UI Application

Summary

Previously published at