1. Exceptions1 Syntax, semantics, and pragmatics

2. Exception create If (some error){ throw new SomeException(”some message”); } Exceptions2

3. Exceptions catch Try{ methods where exception can occur } catch( SomeException se){ do the exception handling } Exceptions3

4. 4 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(); } }

5. Try with resource statement Java 7 language feature The coding idiom –Declare … try { open + use } finally {close } –Is now supported in the Java programming language New syntax –Try (open + initialize) { use } –The resource must implement the java.lang.AutoCloseable interface –Finally is no longer necessary in this case –Further readings + examples The Java Tutorial –http://download.oracle.com/javase/tutorial/essential/exceptions/try ResourceClose.html Exceptions5

6. 6 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.

7. Exceptions7 Item 57: 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.

8. Exceptions8 Item 58: 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 –Examples: IndexOutOfBoundException, NullPointerException

9. Exceptions9 Item 59: 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()

10. Exceptions10 Item 60: 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

11. Exceptions11 Item 61: 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

12. Exceptions12 Item 62: 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 –Mainly with checked exceptions. –Don’t forget the run-time exceptions.

13. Exceptions13 Item 63: 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

14. Exceptions14 Item 64: 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.

15. Exceptions15 Item 65: 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.

16. Exceptions16 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, 2nd edition, Addison Wesley, 2008 –Chapter 9: Exceptions, page 241-258