1 / 22

Exceptions: Bloch

Exceptions: Bloch. SWE 619 Last modified Fall 2007 Saket Kaushik, Paul Ammann. Item 39: Exceptions for Exceptional Conditions. Don’t do this! try{ int i=0; while (true) { a[i++].f(); } }catch(IndexOutOfBoundsException e){} Implications for API design

kalli
Télécharger la présentation

Exceptions: Bloch

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Exceptions: Bloch SWE 619 Last modified Fall 2007 Saket Kaushik, Paul Ammann

  2. Item 39: Exceptions for Exceptional Conditions • Don’t do this! try{ int i=0; while (true) { a[i++].f(); } }catch(IndexOutOfBoundsException e){} • Implications for API design • Provide state testing method instead of forcing client to catch exception. Kaushik, Ammann 2005

  3. More Item 39: • Do this instead for (int i = 0; i < a.length; i++) { a[i].f(); } Note “State Testing method”: i < a.length Kaushik, Ammann 2005

  4. More Item 39: • How about: try{ Iterator i = collection.iterator(); while (true) { Foo foo = (Foo) i.next(); } }catch(NoSuchElementException e){} • versus: for (Iterator i = collection.iterator(); i.hasNext();){ Foo foo = (Foo) i.next(); ... } Kaushik, Ammann 2005

  5. Item 40: Checked vs. Unchecked • Unchecked exceptions indicate programming errors • Precondition violations • Recovery is impossible • Checked exceptions indicate recoverable conditions • Force the caller to handle the exception Kaushik, Ammann 2005

  6. Checked vs. Unchecked (cont’d) • Use unchecked exceptions if • client has nothing to do • OutOfMemoryException • client knows better • doesn’t need try-catch block; if-then block would suffice. • Use checked exceptions if client has some reasonable action • IOException  Calling code is correct, but exception can still be raised! Kaushik, Ammann 2005

  7. Item 41: Avoid Unnecessary Use of Checked Exceptions try{ obj.action(args)} }catch(SomeCheckedException e){ throw new Error (“Assertion Error”) } // should never happen • What is the point of making a client do this? • Conditions for using checked exceptions: • Exceptional condition cannot be prevented by proper use of the API • Programmer can take some useful action Kaushik, Ammann 2005

  8. More Item 41: Standard Transformation: if (obj.actionPermitted(args)) { obj.action(args); } else { // Handle exceptional condition } Or even simply (where appropriate): obj.action(args); // Client allows call to fail Kaushik, Ammann 2005

  9. Item 42: Bloch’s standard exceptions • IllegalArgumentException - Inappropriate parameter; several special cases • NullPointerException (param null where prohibited) • IndexOutOfBoundsException (index param out of range) • ClassCastException • ConcurrentModificationException • Concurrent modification detected when not allowed Kaushik, Ammann 2005

  10. More Item 42 • IllegalStateException • Object state is inappropriate for method invocation • Object may not be initialized before calling accessing its state • UnsupportedOperationException • Object does not support the method • Substitution principal Kaushik, Ammann 2005

  11. More Item 42 • Favor the use of standard exceptions • Using your API is easier • Reading your programs is easier • Performance advantage Kaushik, Ammann 2005

  12. Item 43: Exceptions should make sense to the caller! • Throw exceptions appropriate to the abstraction • Propagated exceptions may make no sense! • Higher layers should translate lower level exceptions try{ … }catch(LowerLevelException e){ throw new HigherLevelException(…); } Kaushik, Ammann 2005

  13. Item 44: Document them all! • Document all exceptions • Liskov and Bloch differ partially • Bloch: document each exception thrown (using JavaDoc @throws tag) • This is semantically eqvt. to Liskov’s Effects clause • Bloch: Don’t mention unchecked exceptions in the signature • Liskov: document all exceptions in Effects clause, AND mention in signature Kaushik, Ammann 2005

  14. Item 45: Add helpful info • Include failure-capture information in detail messages • program failure due to uncaught exception, help messages are printed • these call toString() method on exception • Create exceptions with relevant data, so that it helps developer using it. • In other words, ADD RELEVANT STATE Kaushik, Ammann 2005

  15. Item 46: Failure Atomicity of Procedures • Failure atomicity: • A failed method invocation should leave the object in the state that it was in prior to the invocation • Ways to achieve this effect: • Design immutable objects • Check parameters for validity before performing the operation • Order the computation – parts may fail come before modification • Write recovery code – cause the object to roll back its state • Perform the operation on a temporary copy of the object Kaushik, Ammann 2005

  16. Item 46: Atomicity of Procedures • public int addMax(int [] a, int x) throws … • //Requires: … • //Modifies: a • //Effects: … • Don’t throw exception in between modifications to state variables • Procedure should have an atomic effect • throw exception in the beginning if you are not sure you can pull it off Kaushik, Ammann 2005

  17. More Item 46 • public Object pop() throws … { • //Requires: this != EmptyStack • //Modifies: this • //Effects: pops this and returns top Object result = elements[--size]; elements[size] = null; return result; } // Note: Client can corrupt state – oops! Kaushik, Ammann 2005

  18. More Item 46 • public Object pop() throws … { • //Requires: • //Modifies: this • //Effects: If this empty throw ISE // else pop this and returns top if (size == 0) { throw new ISE(…); Object result = elements[--size]; elements[size] = null; return result; } // Note atomic execution, normal or exception Kaushik, Ammann 2005

  19. Item 47: Don’t ignore exceptions • Programmers should never leave a catch block empty • Its easy to ignore exceptions, but don’t! try{ … }catch(Exception e){ } // empty catch block wont raise complaints from compiler! Don’t do this! Kaushik, Ammann 2005

  20. More Item 47 • If its empty, its highly suspect • The purpose of exception is to force programmers handle exceptional conditions • At least have a comment which explains why its ok to ignore this exception Kaushik, Ammann 2005

  21. Meyer’s View of Exceptions (OO Software Construction) • A procedure either succeeds or fails • If contract is satisfied, procedure succeeds • If not, procedure fails • An exception is an event that may cause a procedure to fail. • A failure of a procedure causes an exceptional return to the caller. Kaushik, Ammann 2005

  22. More Meyer • A procedure will fail if an exception occurs, and the procedure does not recover from the exception. • Only two possible responses to an exception • Retry • Fail (Organized Panic) • Only 1 possible exception in Meyer • Failure Exception (Compare to Liskov) • A bit austere for some tastes - YMMV Kaushik, Ammann 2005

More Related