Error and Exception Handling

Lecture

• What could go wrong?
  • unexpected or inconsistant input
    • syntacticly incorrect - wrong types or values
    • semanticly incorrect

      for example, our old friend bracketRoot(double a, double b), if f(a) and f(b) are the same sign, we are not guaranteed a root and trouble will follow.

  • I/O errors
  • Ex: Attempt to open non-existant file
  • Processing errors
  • Ex: divide by zero; array access out of bounds; null Object access
  • External conditions
  • Network host unreachable; network connection disconnected
  • External device conditions; audio, cameras, etc.
  • System errors (usually fatal)
  • Out of memory; disk errors; hardware errors
• Three issues:
  • Detecting: testing for error conditions
  • Signaling: communicating error to handling code
  • Handling: attempt to recover, or at least die gracefully
• Testing
  • Choices:
    • High level: Test arguments before calling library methods.

      For example, in the case of bracketRoot, check signs before call.

    • Low level: Detect error in called method and pass them up.

      If you are implementing both the caller and callee, one can check for consistancy in the caller and assume all is well in the callee.

      If you are implementing a library or class to be used by others, you probably have to check all inputs for error in your library methods.

  • Choice should be based on program structure, probabilities of error, and cost of testing. At any rate, policy should be clear, explicit and consistant. It should be clear at each level what conditions on input and data values have been check and enforced.
• Signalling
  • Two methods: Error return codes, and Throwing Exceptions
  • Error codes
    • Have all library methods return an error code: usually 0 for success, and a non-zero code specifying type of error.
    • Advantages: low overhead, conceptually simple
    • Disadvantages:
      • uses up return value,
      • caller must test codes after each call, multi-level system must pass errors up the call chain.
    • For example, in our bracketRoot method, we are returning a double so it's hard to return an error code. You can select an unlikely value or return NaN, or null (for Object types)
    • If we really, wanted to (cleanly) use the return value to signal error conditions, we could use it solely for this purpose, and use a shared data structure to return a value. For example we would specify bracketRoot as

      public ErrorCode bracketRoot(double a, double b, double e, double[] val);
      

      and return our answer in val[0]; (In some language (like C on UNIX), this is really the only choice, and many C libraries are specified this way). and many
  • Exceptions
    • Higher overhead, but can lead to cleaner code

Exceptions: General

The basic problems Exception mechanisms are trying to solve are:

• Indicating an error without using up the return value
• Getting the exception to the code that deals with it, with have to constantly check return values.
  The basic process of the exception mechanism is as follows:
  • When error condition is detected an exception is thrown
  • "throw" is a system/language specific mechanism that unwinds the call stack until a handler for the specific exception is found
  • Exception handlers defined in "catch" blocks
  • After processing catch handler code, execution resumes after catch block
  • Many languages/systems have catch/throw exception systems: Java, C++, Windows C (no raw C catch/throw available in UNIX). All of these systems are more or less the same as the Java version

Exceptions: Java

• Errors and Exceptions are Objects (of course). Inherit from Throwable class. Can be subclasses for application specific errors (and are by various libraries). Java actually has a class hierarchy of exceptions (draw it)
• Error represents system error: bugs in the run-time, out-of-memory, etc. These things you can generally do little about.
• The Exception class represents all other condition and has two subclasses
• RuntimeException class represent, essentally, programming errors: arrayAccessOutOfBounds, bad dowencast, NullObject access, etc.
• IOException class represent exceptions from the IO system, such as attempting to open a non-existing file. But can also be subclassed to represent any semantic type of error (for example the inconsistant input condition on bracketRoot())
• In the case of bracketRoot, we might want our own exception class to indicate the type or error. We do this by subclassing:

  public class BracketException extends IOException{
      public BracketException(){};  // empty constructor
      public BracketException(String msg){ super(msg)} //allows error msg
  }
  

Throwing Exceptions

• When it detects an error, a method can throw an exception using the keyword throw which takes an instance of an exception type. For example, in bracketRoot we might have:

     // init fa, fb
     if((fa > 0) && (fb > 0)) || (fa < 0) && (fb < 0)){  // same sign, error!
        throw new BracketException();   // must use new to get instance
     ...
     // code to do stuff
     }
  

• In Java, methods must specify any exceptions they throw, using the keyword throws in the method definition.

  public bracketRoot(double a, double b, double e) throws BracketException{
     // init fa, fb
     if((fa > 0) && (fb > 0)) || (fa < 0) && (fb < 0)){  // same sign, error!
        throw new BracketException();   // must use new to get instance
     ...
     // code to do stuff
     }
  

• Methods are also responsible for dealing with exceptions thrown by any method they call. They can deal in one of two ways:
  • Punt! Let a method higher in the calling chain deal. In this case our punting method must also specify that its throws the error.
  • Actually handle the exception: Our next topic

Exception handling: catch

• The syntax for handling exceptions in Java (and most other systems) is the try,catch>/code> pair.
• Any code that might throw an exception we want to handle is wrapped in a try block. This is followed by one or more catch blocks (one for each Exception type we want to handle) which contains code that handle the error.

  try{
    // Code that can throw an exception
    bracketRoot(a,b,e);
  }
  catch(BracketException e){
    ..Code to handle exception e...
  }
  ..Execution resumes here...
  

• The code in the catch block is ONLY executed when the exception is thrown.
• In either case, execution continues immediate after the last catch block (unless the catch block does a throw).
• Finally blocks are useful for factoring out code that should be executed no matter what: normal execution, caught exception, exception to be passed to higher level (re-thrown).

  try{
    ..Code that can throw an exception..
  }
  catch(Exception e){
    ..Code to handle exception e...
  }
  finally{
    ..Code here always executes. Good place to clean up...
  }
  ..Normal execution resumes here...
  

• Warning: Throw/try/catch mechanism is high overhead. Use sparingly. A little error checking at high level goes a long way.