C1/C2: Review

CPSC 210

C1 Learning Goals
(reminder)

  • Connect the concept of "robustness" to exceptions
  • Construct a throw statement to throw an intended exception
  • Identify what happens next when a segment of a try/catch block completes normally or abnormally
  • Construct an assertion to document and check a condition you do expect to be true in your code

Why Bother? (1)

If the caller provided a path & name that fails..

The catch block logs the issue for debugging and tries to recover using a default.
(If that fails, the exception "escapes".)

Why Bother? (2)

This should be a double, but if it's not..

The catch block stops an implementation-specific exception from "escaping" and replaces it with a detailed, clear exception suitable for public consumption.

Why Bother? (3)

If something goes wrong accessing the DB..

The catch block cleans up before re-throwing the error, like a targeted finally.

(Should they have used finally instead? Maybe!)

Robustness <==> Exceptions

// REQUIRES: f is a writable file; there
//   is enough disk space to store image
// MODIFIES: f
// EFFECTS: writes image to f
public void save(File f, Image image) { ... }

We might instead check for conditions we require or surprising circumstances.

Exceptions give us a way to
signal exceptional circumstances,
handle them if possible, and
crash the program otherwise 

}

Puts a lot of burden on the caller,
some of which is hard to check!

// MODIFIES: f
// EFFECTS: writes image to f if possible
//  if f is not writable, throws IOException
//  if there is not enough disk space,
//    throws DiskFullException
public void save(File f, Image image) throws
    IOException, DiskFullException { ... }

}

// MODIFIES: f
// EFFECTS: writes image to f if possible
//  if f is not a writable file, ?????
//  if there is not enough disk space, ????
public void save(File f, Image image) { ... }

}

throw Statement

throw new ExceptionClass(...);

Any expression with an apparent type that is a subtype of Exception (including Exception)

(Technically Throwable, not Exception.)

To execute the throw:

  1. Evaluate the expression normally.
  2. Discard whatever was planned to execute next and instead commence throwing the exception object.

try/catch/finally: normal flow

previousStatement();
try {
  ...
}
catch (SomeException e) {
  ...
}
finally {
  ...
}
nextStatement();

Normal flow of control for a try:

  1. Execute the try block.
  2. Execute the finally block (if any).
  3. Execute the next statement
    (as with any other statement).

try/catch/finally: catching (1)

previousStatement();
try {
  ...
}
catch (SomeException e) {
  ...
}
finally {
  ...
}
nextStatement();


an exception is thrown from inside the try block and exits (ends) that block.

If a catch matches (the first that can be assigned the exception), normal execution resumes there.

Normal flow of control from catch:

  1. Execute the catch block.
  2. Execute the finally block (if any).
  3. Execute the next statement
    (as with any other statement).

A catch gets a chance if..
 

try/catch/finally: catching (2)

previousStatement();
try {
  ...
}
catch (SomeException e) {
  ...
}
finally {
  ...
}
nextStatement();


an exception is thrown from inside the try block and exits (ends) that block.

If no catch matches, the exception exits (ends) the try/catches.

A catch gets a chance if..
 

Or: If a catch did match but then it threw an exception, that also exits (ends) the try/catches.


then resumes the exception. Either way, the try statement ends with the exception.

If there is a finally, it executes normally.. 

assert Statements

assert someBooleanExpression; // or
assert someBooleanExpression : valueExpression;

An expression with an apparent type of boolean to check.

To execute the assert:

  1. Evaluate the boolean expression normally.
  2. If its result is true, continue to the next statement.
    Otherwise stop with an error. If the value expression is present, it's evaluated to get the error message.

 

But: If assertions are disabled, the whole statement is ignored.

Used as the error message on failure

C2 Learning Goals
(reminder)

  • To design appropriate exception hierarchies to provide flexibility in handling exceptions
  • To identify and declare exceptions as checked or unchecked (and also use unchecked exceptions)

Hierarchies and Unchecked Exceptions

Throwable

Object

Error

Exception

RuntimeException

...

...

Unchecked Exceptions

Checked Exceptions

C1/C2: Review

The End - Thank You!

CPSC210 - C1/C2 Video Review

By Steven Wolfman

Made with Slides.com

CPSC210 - C1/C2 Video Review

  • 99

More from Steven Wolfman