Download Slides (exceptions)

Exceptions and Assertions
Syntax, semantics, and
pragmatics
Exceptions
1
Syntax, semantics, pragmatics
• Syntax
– How it looks, i.e. how we have to program to
satisfy the compiler.
• Semantics
– What it means / how it works
• Pragmatics
– How to use it in the proper way.
Exceptions
2
Introduction
• Exceptions are a part of the Java
programming language
– And other programming languages like C++,
C#, etc.
• Exception related keywords in Java
– Throw, throws, try … catch … finally
Exceptions
3
Exception classes
Throwable
-message : String
-cause : Throwable
+getMessage() : String
+getCause() : Throwable
+toString() : String
Exception
Error
Indicate problems
inside the JVM
IOException
MyOwnException
RuntimeException
Unchecked
exceptions
Checked exceptions
NullPointerException
Exceptions
4
Exception class hierarchy
• The class hierarchy can get pretty deep
– java.lang.Object
• java.lang.Throwable
– java.lang.Exception
» java.sql.SQLException
»
java.ql.SQLWarning
– More detailed exceptions
• More detailed handling
Exceptions
5
Checked vs. runtime exceptions
• Checked exceptions
– Extends Exception, directly or indirectly.
– Must be caught or declared to be thrown
• This is checked by the compiler
– Can usually be recovered from at runtime
• Run-time exceptions
– Extends RuntimeException, directly or indirectly
– Can be caught or declared to be thrown
• This is not checked by the compiler
– Cannot be recovered from at runtime
Exceptions
6
The class Error
• By convention the class Error is reserved
for use by the JVM to indicate problems in
the JVM.
– Don’t ever subclass Error
– Don’t ever throw an Error
• Unless you are programming a JVM, of course!
Exceptions
7
What happens when an exception
is thrown?
• When an exception is thrown the current
block ({…}) is popped of the call stack
• This popping continues until some block
has a catch clause.
• If no block has a catch clause we will
eventually end in main, which is then
popped
– And the program stops.
Exceptions
8
Sequence of catch blocks
• If a block has more than one catch block
the first catch block, that matches the
exception type, is executed.
• General rule:
– Special exception must be caught before
general exceptions
Try { … }
catch (FileNotFoundException ex) { …}
catch (IOException ex) { …}
Exceptions
9
Different kinds of exception
handling
• Ignore
– Usually a bad programming habit used by 1st semester students
to make the compiler shut up!
• Handle
– Only handle the exception if you really can.
– Just printing something to the screen is usually a bad idea,
except if you are in the user interface layer.
• Re-throw
– If you don’t know how to deal with the exception re-throw it.
• Partly handle + re-throw
– Sometimes you want to partly handle the exception for example
write to a log file, and then re-throw the exception.
Exceptions
10
Finally
• The finally block is executed whether or not an
exception is thrown.
– Leaving the method you always execute the finally
block
• Used to release resources
– Example: Closing a connection to a network,
database, or file
– Coding idiom:
FileReader input = null;
try { … open input and use it … }
finally { if (input != null) { input.close(); } }
Exceptions
11
Program your own exception
• Why?
– Technical exceptions like IOException,
SQLException, etc. should not be propagated to the
model layer.
– Instead you must define your own application specific
exception like LibraryException
• How? That’s very easy!
– Define a new class which extends the class Exception
– You probably need to define 3 constructors.
– Your exception class may have data + methods
• But you probably never need it.
– NetBeans can assist you.
Exceptions
12
Item 39: Use exceptions only for
exceptional conditions
• Don’t loop over a collection until it throws
an exception.
• Only throw exceptions if the state is really
exceptional
– Searching for something without finding it, is
that exceptional? Probably not. Better to
return null.
Exceptions
13
Item 40: Checked exceptions vs.
run-time exceptions
• Use checked exceptions for recoverable
conditions and run-time exceptions for
programming errors
– Use checked exception for conditions form which the
call can reasonably be expected to recover.
– Use run-time exceptions to indicate programming
error
• The caller made an error
– Most likely a violation the methods precondition
– Example: ArrayIndexOutOfBoundException,
NullPointerException
Exceptions
14
Item 41: Avoid unnecessary use of
checked exceptions
• If the caller cannot handle the exception,
then throw a run-time exception.
• Provide check methods
– Example: StringTokenizer.hasMoreElements()
Exceptions
15
Item 42: Favor the use of standard
exceptions
• Don’t use a home-made exception if you
can use a standard exception.
• Specially with run-time exceptions.
• Reusable standard run-time exceptions
– IllegalArgumentException
– IllegalStateException
– NullPointerException
– IndexOutOfBoundsException
– UnsupporteOperationException
Exceptions
16
Item 43: Throw exceptions
appropriate to the abstraction
• Higher layers should catch lower-level
exceptions and throw exceptions appropriate for
the higher level
• Exception translation
– Catch (LowLevelException ex) { throw new
HighLevelException(message); }
• Exception chaining
– Catch (LowLevelException ex) { throw new
HighLevelException(ex); }
– The LowLevelException is “inside” the
HighLevelException
– New in Java 1.4: New constructor in class Throwable
Exceptions
17
Item 44: Document all exceptions
thrown by each method
• For all your methods
– Document (using the Javadoc @throws tag)
all the exceptions the method might throw
– Including unchecked exceptions.
• NetBeans can assist you
– But only with checked exceptions.
– Don’t forget the run-time exceptions.
• Don’t use the throws keyword to include
run-time exceptions.
Exceptions
18
Item 45: Include failure-capture
information in detail message
• The message in the exception is the only
information the receiver gets.
• The message in the exception should
include all values that “contributed” to the
exception
Exceptions
19
Item 46: Strive for failure atomicity
• A failed method should invocation should
leave the object in the state that it was
prior to invocation.
– Easier to recover from exception.
Exceptions
20
Item 47: Don’t ignore exceptions
• An empty catch block is highly suspicious
– If you really mean it, then write a comment in
the empty catch block.
Exceptions
21
References
• Ken Arnold et al.: The
Java Programming
Language, 4th edition,
Addison Wesley, 2006
– Chapter 12: Exceptions
and Assertions, page 279303
• Joshua Bloch: Effective
Java, Addison Wesley,
2001
– Chapter 8: Exceptions,
page 169-187
Exceptions
22