Exceptions: CS 310 Lecture notes

Object-Oriented Programming with Java Lecture Notes

3 March 2009 • Exceptions

Outline

The error problem.
Exception basics.
- throw, try, and catch.
The exception hierarchy.
- Checked and unchecked exceptions.
Exception mechanism refinements.

Errors

What happens if there’s an error in a constructor?
```
Blob b = new Blob();
```
What happens if something goes wrong way down there?
- Way down deep in a library.
What’s the code to do?

The Error Pass-Along Problem

The code at the error source may not be able to handle the error.
- Unknown context makes error handling difficult.
Printing an error message and dying is helpful, but not always useful.
Give up (after local clean-up, if needed) and pass the error along.
- Better, but how?

Error Return

Methods can return error-status values.
```
Error e = ci.m();
if (e.status == Error.ok) { ... }
```
- Complicates value-returning methods.
- Constructors can’t return any values.

Error Parameters

Pass error values through method parameters.

void m(args, Error error) { ... }

ci.m(..., e)
if (e.status != Error.ok) { ... }

Not object pure.
- Or setter-getter clumsy if it is.
Works for constructors.

Error Globals

Use a global to pass error values.

ci.m();
if (error.status != Error.ok) { ... }

Not well structured, not thread safe.

Exceptions

Exceptions provide an alternative mechanism for delivering error indications.
Exceptions are not propagated along parameters, return values, or globals.
- This is known as out-of-band communication.
Uninterested code can chose to ignore exceptions.
- But, alas, it’s not that simple.

Exception Basics

Each method call has a stack frame.
- The stack frame holds parameters, local variables, and other things related to the method. call
The call stack contains the stack frames of all current method calls
When one one method calls another, the called method pushes its stack frame on the call stack.
When the top method returns, it pops its call stack frame off the call stack.

Call-Stack Example.

Consider

int main () { ci.f() }              

int f() { ci.g() }         

int g() { if (b) ci.g() }

Initially main() is called, and e() calls f().

Call-Stack Example..

f() then calls g().
Eventually f() and g() return.
main() returns and the program ends.

Exceptions and the Call Stack

The top of the call stack can throw an exception.
- This terminates the throwing method, popping it from the call stack.
Each new call-stack top may catch the exception, or let it pass.
- Catching the exception continues execution at the catching method.
- Letting the exception pass terminates the method, popping it from the call stack.

Stack Unwinding

throwing an exception

Popping the call stack because of exceptions is known as unwinding the call stack.
Completely unwinding the call stack terminates the program.

Exception Problems

Exceptions are completely different from everything else.
- Another new and different thing to watch.
Coordinated exceptions among independent modules requires work.
- Which methods throw what exceptions when?
Unwinding the call stack is violent: it may occur unexpectedly, and the consequences are severe.

Basic Exception Mechanisms

Java has three components for dealing with exceptions:
1. The throw statement throws exceptions.
2. The try block delimits exception handling.
3. The catch block catches exceptions.
There are other components too.

The `throw` Statement

The throw statement signals (throws, raises) an exception:
throw exception-ref;
- Like return in syntax and semantics.
```
throw new NullPointerException();

final NullPointerException e = 
  new NullPointerException();
throw e;
```

The `catch` Block

A catch block catches thrown exceptions:
catch ( ex-type ex-name ) { body }
- This syntax is similar to a one-parameter method definition.
```
catch (ExceptionType e) {
  // blah blah blah
  }
```
ex-name is accessible only within the catch body.

The `try` Block

An exception can be caught only when it’s thrown from within a try block:
try { body }
- An exception thrown outside a try block immediately unwinds that method.
A try block is its own scope.
- Variables declared in a try block are inaccessible outside it.

Try-Catch Statements

A try block and one or more catch blocks from a try-catch statement:

try { body }
catch ( ex-type ex-name ) { body }
catch ( ex-type ex-name ) { body }
// and so on

This is the basic exception-handling unit.

Normal Try-Catch Control

Execute try-block code.
Control falls off the try-block end.
Execution resumes with the statement following the try-catch block.
- The catch blocks are ignored.

normal try-catch control flow

Handled Exceptions

Jump from the try block to the catch blocks on exception.

Immediate but normal try-block scope exit.

Search for a matching catch block in order.

An exception is considered handled as soon as a match is found.

After executing the associated catch body, continue after the try-catch statement.

Example

handled exception control flow

Assuming the catch block doesn’t throw another exception.

Unhandled Exceptions

If no catch block matches, terminate the current method and continue unwinding the stack.
Assuming there’s no nested try-catch statement involved.

handled exception control flow

Exception Clean-Up

Exceptions occur at inconvenient times.

try { 
  // state set-up
  ci.g()
  // state tear-down
  }
catch (...) { ... }
catch (...) { ... }

ci.g()’s exception interrupts state tear-down.

Duplicate code in the catch blocks.

`finally` Blocks

A try-catch statement’s finally block

finally { code }

is always executed, exception or not, exception handled or not.

try { 
  // state set-up
  ci.g()
  }
catch (...) { ... }
catch (...) { ... }
finally { // state tear-down }

Finally Examples

normal finally block

handled finally block

propagating finally block

none

handled

propagated

Matching Exceptions

Exceptions match using assignment compatibility.
A catch block with exception type ET catches exception of type TET when TET is an descendant of ET.
The first matching exception wins, not the closest.
- Order the exceptions from most specific to most general in a try-catch statement.

The Exception Hierarchy

the top of the java exception hierarchy

The `Throwable` Ancestor

The Throwable class is the top of the exception hierarchy.

Has constructors

Throwable(String message, Throwable cause)
Throwable(String message)
Throwable(Throwable cause)
Throwable()

Also the expected getters and setters.

See the JavaDoc API page for more details.

The `Error` Class

The Throwable child Error defines abnormal conditions.
- “Abnormal” means end-of-the world conditions, internal failures, and the like.
Applications should ignore Error-based exceptions, and should not throw them.
- The situation's so bad, nothing works anyway.
Example Error children include VirtualMachineError and AssertionError.

The `Exception` Class

The Throwable child Exception defines undesirable conditions the application should handle.
- Or at least react to.
Exception is a useful catch-all in a catch block.
Applications should throw leaf Exception descendants.
- Throw as much information as possible to help recovery.

`Exception` Children

The Exception child IOException defines undesirable conditions related to input-output operations.
- Examples include FileNotFoundException and EOFException.
The Exception child RuntimeException defines undesirable conditions related to non-I/O execution.
- Examples include ClassCastExcepton and NullPointerException.

The Exception Hierarchy

the top of the java exception hierarchy

Throwable: exception root.

Error: neither thrown nor caught.

Exception: checked exception root. (almost)

Runtime: unchecked exceptions.

Avoidable vs. Fateful Occurrences

An avoidable occurrence is one that could be prevented with a reasonable amount of care.
- A null-pointer reference is an avoidable occurrence.
- So is an downcast to a non-ancestor class.
A fateful occurrence cannot reasonably be prevented.
- Writing to a full disk, accessing a missing web server.

Handling Occurrences

There is no good excuse for encountering an avoidable occurrence.
- It results from ignorance, indolence, or incompetence.
There is not good protection against encountering a fateful occurrence.
- Protection against fate is costly verses the benefit gained.

Checked vs. Unchecked Exceptions

Java uses checked exceptions to “help” with fateful occurrences.
A checked exception must be explicitly announced as a possibility.
- An unchecked exception requires no such announcement.
Exception and all ancestors (except Runtime) are checked.
Runtime and Error exceptions are unchecked.

The `throws` Clause

A method announces a checked exception via a throws clause:
```
throws ex [ , ex ]...
```
A throws clause appears after the method’s signature
```
String read()
throws IOException { ... }
```
A method propagating an unlisted checked exception causes a compile-time error.

Inheritance and `throws`

A child method overriding a parent method cannot throw more exceptions than the parent method does.
- It may throw fewer; it may throw none.
The child exception types thrown must be descendants of the parent exception types.
The throws clause doesn’t take part in determining the override.

Example

class RedException extends Exception { ... }
class BlueException extends Exception { ... }

class p
  int moo() throws RedException { ... }

class c1 extends p
  int moo() 
  throws RedException, BlueException  { ... }

class c2 extends p
  int moo() throws Exception { ... }

class c3 extends p
  int moo() { ... }

Javadoc and Exceptions

List exceptions in Javadoc with the @throws tag.
List checked exceptions in Javadoc as well as in throws clauses.
Document unchecked exceptions only in Javadoc.
- Throws clauses are scary (because of the responsibilities),
  big throws classes are even scarier,
  unnecessarily big throws clauses are annoying.

Defining Exceptions

Reasonably involved packages should define an exception set if applicable.
- Classes that have their own exception set are probably too big.
Determine if the exception set is checked or unchecked (or both, which is a pain).
Extend the most distant ancestor of Exception that seems appropriate.

Exception-Defining Tips

Use existing exceptions if possible.
- Such as IllegalArgumentException or UnsupportedOperationException.
Go easy on the checked exceptions.
- And don’t freak on the taxonomy.
Define leaf exceptions for throwing; parent exceptions for extending.

Exceptional Exceptions

Exceptions are expensive and obscure.
- Unwinding the stack is disruptive.
- Exceptions start down there, wind through here, and may go up there.
Exceptions should be mark rare, unusual, and significant events.
- Avoid using exceptions for run-of-the-mill control and communication.

Example

try
  int i = 0;
  while true
    f(a[i++])
catch (Exception e)
  // nothing

Loops are optimized; exceptions are not.

f()’s exceptions are masked.

Selective catch clauses don’t help.

Control is quickly obscured with more code.
However, some thoughtfully disagree.

Runtime Exceptions

Do not ignore runtime exceptions.
- Your code’s doing something wrong; fix it.
- This is particularly true for null-pointer access and array-index errors.
Runtime exceptions may occur at the edges of your code.
- Where your code rubs up against not-your code.

Example

The problem.

Exceptions thrown during execution (count exception): 
   360 java.lang.StringIndexOutOfBoundsException
  1771 java.lang.NullPointerException
    36 java.lang.RuntimeException

  
 The cause.

// TODO REMOVE ALL STACK TRACES!!!!
catch(StringIndexOutOfBoundsException f)
{  }
catch(NullPointerException f)
{ }

Summary

Consider alternative, non-exception error-handling techniques.
Use exceptions in exceptional, potentially troublesome circumstances.
Document exception use.

Credits

Black Swan by davesag under an AT, NC, SA Creative Commons license.

Object-Oriented Programming with Java Lecture Notes

3 March 2009 • Exceptions

Outline

Errors

The Error Pass-Along Problem

Error Return

Error Parameters

Error Globals

Exceptions

Exception Basics

Call-Stack Example.

Call-Stack Example..

Exceptions and the Call Stack

Stack Unwinding

Exception Problems

Basic Exception Mechanisms

The throw Statement

The catch Block

The try Block

Try-Catch Statements

Normal Try-Catch Control

Handled Exceptions

Example

Unhandled Exceptions

Exception Clean-Up

finally Blocks

Finally Examples

Matching Exceptions

The Exception Hierarchy

The Throwable Ancestor

The Error Class

The Exception Class

Exception Children

The Exception Hierarchy

Avoidable vs. Fateful Occurrences

Handling Occurrences

Checked vs. Unchecked Exceptions

The throws Clause

Inheritance and throws

Example

Javadoc and Exceptions

Defining Exceptions

Exception-Defining Tips

Exceptional Exceptions

Example

Runtime Exceptions

Example

Summary

Credits

The `throw` Statement

The `catch` Block

The `try` Block

`finally` Blocks

The `Throwable` Ancestor

The `Error` Class

The `Exception` Class

`Exception` Children

The `throws` Clause

Inheritance and `throws`