1. Exceptions1 Syntax, semantics, and pragmatics

2. Exceptions2 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.

3. Exceptions3 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

4. More syntax: Multi catch General try … catch –try { do something dangerous} –catch (SomeException ex) { handle the exception} Multi catch –Java 7 feature Catch (SomeExceptionType | SomeOtherExceptionType ex) { Handle exception} –Useful if you want the same handling for different exceptions Exceptions4

5. 5 Exception classes

6. Exceptions6 Exception class hierarchy The class hierarchy can get quite deep –java.lang.Object java.lang.Throwable –java.lang.Exception »java.sql.SQLException » java.ql.SQLWarning –More detailed exceptions More detailed information on the problem More detailed handling of the problem

7. Exceptions7 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 Called the “Catch or specify requirement” –http://download.oracle.com/javase/tutorial/essential/exceptions/catchOrDecla re.htmlhttp://download.oracle.com/javase/tutorial/essential/exceptions/catchOrDecla re.html –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 –Can usually not be recovered from at runtime

8. Exceptions8 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!

9. Exceptions9 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.

10. Exceptions10 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) { …}

11. Exceptions11 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.

12. Exceptions12 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(); } } Example: java7exceptionfeatures

13. 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 –Example: java7exceptionfeatures –Further readings + examples The Java Tutorial –http://download.oracle.com/javase/tutorial/essential/exceptions/try ResourceClose.html Exceptions13

14. Exceptions14 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 –Example: eventLayersExceptions 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.

15. Exceptions15 Item 57: Use exceptions only for exceptional conditions Don’t loop over a collection until it throws an exception. A well-designed API must not force the users to use exception for ordinary control flow

16. Exceptions16 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 (programmer) made an error –Most likely a violation the methods precondition –Examples: IndexOutOfBoundException, NullPointerException

17. Exceptions17 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()

18. Exceptions18 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

19. Exceptions19 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

20. Exceptions20 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.

21. Exceptions21 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 –Example throw new IllegalArgumentException(“….” + parameter)

22. Exceptions22 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.

23. Exceptions23 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. –In JUnit test you sometimes see an empty catch block But even here you can improve catch (SomeException ex) { assertEquals(“….”, ex.getMessage(); }

24. Exceptions24 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