160 likes | 251 Views
Exceptions. Syntax, semantics, and pragmatics. Exception create. If ( some error ){ throw new SomeException (” some message ”); }. Exceptions catch. Try { methods where exception can occur } catch ( SomeException se){ do the exception handling }. Finally.
E N D
Exceptions Syntax, semantics, and pragmatics Exceptions
Exceptioncreate If (someerror){throw new SomeException(”somemessage”); } Exceptions
Exceptionscatch Try{ methodswhereexceptioncanoccur } catch( SomeException se){ do the exception handling } Exceptions
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
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/tryResourceClose.html Exceptions
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
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. Exceptions
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 Exceptions
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() Exceptions
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 Exceptions
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 Exceptions
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. Exceptions
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 Exceptions
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. Exceptions
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. Exceptions
References • Ken Arnold et al.: The Java Programming Language, 4th 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 Exceptions