Exceptions
1
Exceptions and Assertions
Syntax, semantics, and
pragmatics
Exceptions
2
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
3
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
4
Exception classes
RuntimeException
+
getMessage
() :
String
+
getCause
() :
Throwable
+
toString
() :
String
-
message
:
String
-
cause
:
Throwable
Throwable
Exception
Error
IOException
NullPointerException
MyOwnException
Indicate problems
inside the JVM
Checked exceptions
Unchecked
exceptions
Exceptions
5
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
6
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
7
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
8
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
9
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
10
Different kinds of exception
handling
•
Ignore
–
Usually a bad programming habit used by 1
st
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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
22
References
•
Ken Arnold et al.:
The
Java Programming
Language
, 4
th
edition,
Addison Wesley, 2006
–
Chapter 12: Exceptions
and Assertions, page 279
-
303
•
Joshua Bloch:
Effective
Java
, Addison Wesley,
2001
–
Chapter 8: Exceptions,
page 169
-
187
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment