This document discusses exception handling in Java. It defines exceptions as events that disrupt normal program flow. It describes try/catch blocks for handling exceptions and lists advantages like separating error handling code. It discusses different exception types like checked exceptions that must be declared, unchecked exceptions for logic errors, and Errors for JVM problems. It provides best practices like throwing exceptions for broken contracts and guidelines for when to catch exceptions. It also describes antipatterns to avoid, like catching generic exceptions, and exception logging and chaining techniques.
2. What is Exception
An exception is an event, which occurs
during the execution of a program, that
disrupts the normal flow of the program's
instructions.
6. Checked exceptions
Part of the method signature
Compile type checking
Requires programmer to handle the
exception or declare the method as
throws exception
Unique to java
e.g. FileNotFoundException
7. Unchecked exceptions
No need to declare the exception in
method’s signature
No compile time checking
Usually indicate programming error
e.g. NullPointerException
8. Error
Indicate error in the underlying JVM
Error are external to the application
Application does not usually have to
deal with these class of Exceptions
e.g. OutOfMemoryError
9. When to throw exceptions
Exceptions indicate a broken contract
Precondition (e.g. file is open for read)
Postcondition (e.g. read a character from
file)
Your method encounters an abnormal
condition that it can't handle
If your method is unable to fulfill its
contract, throw either a checked or
unchecked exception.
10. What to throw?
Exceptions v/s Errors
Errors are for JVM
Exceptions for rest of us
Checked v/s Unchecked exceptions
Can caller recover from this error?
Yes: checked
No: unchecked
11. When to catch exception
1. When you can handle the exception
2. When you need to throw a different
type of exception
3. Refer to 1 & 2
12. When not to throw an
exception
To achieve Flow control using exception
try {
}
while (true) {
increaseCount();
}
} catch (MaximumCountReachedException ex) {
}
//Continue execution
public void increaseCount()
throws MaximumCountReachedException {
if (count >= 5000)
throw new MaximumCountReachedException();
}
13. 3 rules
What went wrong?
Where did it go wrong?
Why did it go wrong?
If your exception does not provide
answers to all these questions, you
are doing something wrong!
14. Performance implications of
exceptions
Exceptions are expensive for the JVM
Creating stack traces requires
resources and CPU
the Java VM requires more efforts to
handle a thrown exception than a
normal method
15. Anti Patterns
Log and Throw
Throwing Generic Exception
Catching Generic Exception
Destructive Wrapping
Log and Return Null
Catch and Ignore (a.k.a. Head in the Sand)
Throw from Within Finally
Multi-Line Log Messages
Unsupported Operation Returning Null
16. Anti Patterns - Log and Throw
Log the error and throw the same
exception again
Messy log file
Achieves nothing
17. Anti Patterns - Throwing Generic
Exception
The caller does not know the nature
of error – hinders error handling
18. Anti Patterns - Catching Generic
Exception
We are masking programming errors
25. Anti Patterns - Unsupported
Operation Returning Null
public String foo() {
// Not supported in this
implementation.
return null;
}
Throw
UnsupportedOperationException
26. Best practices
Throw checked exception when caller can recover
from error
Throw runtime exception when the caller cannot
recover
Throw runtime exception for programming error
Throw early, catch late
Use NestedException
Don’t catch an exception if you cant do any thing
about it.
Log exception only once, and at the latest possible
time
Default Error Page in presentation layer for all
Runtime Exceptions
28. Exception logging
Log all internal states
Log all parameters to the method
that failed
Log all data required to trace the
error
Ensure log statements don’t cause
NPE*
29. Exceptions in a typical enterprise
applications
Define a hierarchy of exceptions.
Lower level module throws lower level
exceptions, higher level module
encapsulate lower level exceptions
Define which exceptions will cause
transaction to rollback
32. references
Best practices in EJB exception handling
http://www.ibm.com/developerworks/library/j-ejbexcept.html
Beware the dangers of generic Exceptions
http://www.javaworld.com/javaworld/jw-10-2003/jw-1003generics.html
Exception Handling in Web Applications
http://weblogs.java.net/blog/crazybob/archive/2004/02/exception_han
dl.html
Designing with Exceptions
http://www.artima.com/designtechniques/desexceptP.html
Build a better exception-handling framework
http://www.ibm.com/developerworks/java/library/j-ejb01283.html
33. References (cont…)
JAVA EXCEPTIONS
http://www.javaolympus.com/J2SE/Exceptions/JavaExceptions.jsp
Exception-Handling Antipatterns
http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html
Three Rules for Effective Exception Handling
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
13 Exceptional Exception Handling Techniques
http://www.manageability.org/blog/stuff/exceptional-exception-handling-techniques
Best Practices for Exception Handling
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
Lesson: Exceptions
http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html
Editor's Notes
Class not found
Class cast to the interface SomeInterface
Both types of exceptions are handled in the catch block, but that’s not evident by casual inspection of the code.