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. Exceptions4 Exception classes

5. Exceptions5 Exception class hierarchy The class hierarchy can get pretty deep –java.lang.Throwablejava.lang.Throwable java.lang.Exception –java.io.IOExceptionjava.io.IOException »java.net.SocketExceptionjava.net.SocketException » java.net.BindException –More detailed exceptions More detailed handling

6. Exceptions6 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 Run-time exceptions –Extends RuntimeException, directly or indirectly –Can be caught or declared to be thrown This is not checked by the compiler

7. Exceptions7 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!

8. Exceptions8 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 the popped –And the program stops.

9. Exceptions9 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) { …}

10. Exceptions10 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.

11. Exceptions11 Finally The finally clause is executed whether or not an exception is thrown. –Leaving the method you always execute the finally clause Used to release resources –Example: Closing a connection to a network / database / file –Coding idiom: FileReader fr = null; try { … open fr and use it … } finally { if (fr != null) { fr.close(); } }

12. Exceptions12 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.

13. Exceptions13 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.

14. Exceptions14 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 violating the methods precondition –Example: ArrayIndexOutOfBoundException, NullPointerException

15. Exceptions15 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()

16. Exceptions16 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

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

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

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

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

21. Exceptions21 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.

22. Exceptions22 References Ken Arnold et al.: The Java Programming Language, 3 rd edition, Addison Wesley, 2000 –Chapter 8: Exceptions, page 195-208 Joshua Bloch: Effective Java, Addison Wesley, 2001 –Chapter 8: Exceptions, page 169-187