Java Exception Handling

Exception Mechanism

• when an error or exceptional condition occurs, you throw an exception which is caught by an exception handler

    try (
      // block of statements at least one of 
      // which may throw an exception
      if (someCondition)
        throw new ExceptionName (); 
      // most throws are from library methods..
    } catch (ExceptionName e) {
      // block of statements to be executed if
      // the ExceptionName exception is thrown 
    } ...
    } catch (Exc2 e) {
      // block of statements to be executed if
      // the Exc2 exception is thrown
    } finally {
      // optional block of statements 
      // executed whether exception or not 
    }
  

• when searching for a catch block to handle an exception thrown, Java searches upward through the dynamic activation stack of method calls until it finds a matching catch block

• if a try block or a catch clause contains a return statement, the finally block is (as always under all circumstances) executed before the return
• however, if a finally block itself contains a return it then masks off the original return in the try statement:

    public static f (int n) {
      try (
        ...
        int result = n * n; 
        return result; 
      } ...
      } finally {
        if (n == 2) return 0; 
      }
    }
  

• moreover, if a finally block itself throws an exception, the original exception becomes permanently lost
• as a rule, all clean-up code such as finally should be programmed not to throw any exceptions; unfortunately, library methods do not necessarily respect the right spirit of exception handling

• generally, there are many ways to handle an exception:
  1. let Java handle it
  2. fix the problem that let to the exception and resume the program; often, erroneous conditions are difficult or impossible to fix
  3. log the problem and resume the program
  4. log the problem and rethrow the exception
  5. chain a low-level exception within a new higher-level exception (wrap inside as a parameter) and throw that
  6. print/log out an error message and terminate the program immediately

• no one-for-all solution, depends strongly on the specific requirements of the application
• it may well be OK to simply terminate the program, and let the user try with better input

• checked exceptions are caught by the method in which they occur, or you must declare that the method throws the exception
• checked exceptions force the programmer to deal with exceptional conditions; error situations become explicit and in principle the program becomes more reliable
• unchecked exceptions extend RunTimeException and, if uncaught, are handled by Java
• use checked exceptions for recoverable conditions and RunTimeExceptions for programming errors

Guidelines for the use of exceptions

• use exceptions only for exceptional conditions, not for ordinary control flow
• don't ignore exceptions

    try {
      ...
    } catch (SomeException e) {
      // OK, don't worry
    }
  

• in some situations, the programmer may "know" that the code cannot throw any exceptions whatsoever; of course, then it should be well documented and checked:

    try {
      ...
    } catch (SomeException e) {
      // cannot throw exceptions
      assert false; // so shouldn't get here
    }
  

• avoid unnecessary use of checked exceptions, for example
  • reaching the end of a list should not throw a checked exception
  • the API offers a query method (hasNext) that the programmer should use to find out whether its appropriate to advance
  • NoSuchElementException is a run-time exception that indicates a programming error

• favor the use of standard exceptions, for example:

  Commonly Used Exceptions

  Exception	Semantics
  IllegalArgumentException	Parameter value is inappropriate
  IllegalStateException	state is inappropriate for method call
  NullPointerException	null value where prohited
  IndexOutOfBoundsException	index out of range
  ConcurrentModificationException	Modification of object has been detected where prohibited
  UnsupportedOperationException	Object does not support method

• document all exceptions thrown by each method using the Javadoc @throws tag
• do not use the throws keyword to include unchecked exceptions in the method declaration
• for debugging, the string represention of an exception should contain the values of all objects that "contributed" to the exception

• higher layers should catch lower-level exceptions, and in their place, throw exceptions that are explainable in terms of the higher-level abstraction
• for example, a get () method may call more primitive operations with their own exceptions; the method should perform exception translation:

    /**
     * Returns the element at the specified position in this list.
     * @throws IndexOutOfBoundsException if out of range. 
     */
     public Object get (int index) {
       ListIterator it = listIterator (index); 
       try {
         return it.next (); 
       } catch (NoSuchElementException e) {
         throw new IndexOutOfBoundsException ("Index: " + index); 
       }
    } // get
  

• in exception chaining a lower-level exception is stored by the higher-level exception for debugging purposes:

    try {
      lowLevelOperation ();
    } catch (LowLevelException e) {
       throw new HighLevelException (e); // has chaining constructor
    }
  

• the class Throwable provides methods Throwable getCause () and Throwable initCause (Throwable cause) to get and set the original cause of the error situation

• finally, attempt to achieve failure atomicity: a failed method should always leave the system in the state it was in prior to the call

    public Object pop () {
      if (size () == 0)
        throw new NoSuchElementException ();   
      Object result = elements [--size]; 
      elements [size] = null; // eliminate old reference
      return result; 
    }
  

• failure atomicity is expecially important for checked exceptions, from which the caller is expected to recover
• general recovery is not possible if the system is left in an undetermined, possibly faulty state

Stroustrup on exception handling techniques

Stroustrup [The C++ Programming Language, 3rd Ed.. Addison-Wesley, USA, 1997] gives the following advice on C++ exception handling (pp. 386-387 and in Appendix E); these principles may be applied to Java as well:

• A library shouldn't produce diagnostic output at an end user, or independently terminate a program. Instead, throw an exception and let a caller decide.

• Not every program needs to be exception safe. A simple application may produce a suitable diagnostic, let the system release all acquired resources, and let the user re-run the program with a more suitable input.

• Keep ordinary code and error-handling code separate.

• Throw an exception to indicate failure in a constructor. Be sure that every system resource acquired in a constructor is released when throwing an exception in that constructor.

• Do not throw exceptions from any clean-up code such as finally clauses. This may be difficult to ascertain when calling library methods.

• Have main () catch and report all exceptions(?).

• Define a class invariant to make it clear what is a valid state.

• Don't destroy "old" information until its replacement has been safely produced. Only after completing the dangerous calculation, swap the new results into place.

• Provide the Basic Guarantee for exception safety for all classes:

      "maintain the class invariant and don't leak resourses".

• When possible, provide the Strong Guarantee for exception safety :

      "an operation either succeeds or leaves all operands unchanged" (failure atomicity).

• Some primitive operations, such as object reference assignments, provide the Nothrow Guarantee for exception safety:

      "always succeed without throwing an exception".

• Note that Nothrow Guarantee is the ultimate safety guarantee: code that cannot fail!

  • For example, using reference assigments calculated results can be safely swapped to bring out a new valid state.

  • Unfortunately, you usually cannot altogether rule out exceptions in any code that calls existing software or libraries. Only secure language primitives may generally provide Nothrow Guarantee.