Administrativa Principles of Software Construction: Objects, Design, and Concurrency • Midterm 1: Thursday here (Part 2: Designing (Sub-)Systems) • Practice midterm on Piazza • Review session tomorrow, 7pm HBH 100 Design for Robustness • HW 2 grades Christian Kästner Charlie Garrod • HW 4 out, Milestone A due Feb 19 – Do not underestimate design School of Computer Science 2 3 15-214 15-214 15-214 1 2 3 Which design is better? Argue with design goals, principles, heuristics, and patterns that you know Learning Goals Design Goals, Principles, and Patterns • Use exceptions to write robust programs • Design Goals • Make error handling explicit in interfaces and – Design for robustness • Design Principle contracts • Isolate errors modularly – Modular protection – Explicit interfaces • Test complex interactions locally • Supporting Language Features • Test for error conditions – Exceptions 5 6 15-214 * old midterm question 15-214 15-214 4 5 6 1
What does this code do? Additional Readings FileInputStream fIn = new FileInputStream(filename); if (fIN == null ) { switch (errno) { • Textbook Chapter 36 (handling failure, case _ENOFILE: System.err.println (“File not found: “ + …); exceptions, proxy) return -1; default : System.err.println (“Something else bad happened: “ + …); return -1; } } DataInput dataInput = new DataInputStream(fIn); if (dataInput == null ) { System.err.println (“Unknown internal error.”); return -1; // errno > 0 set by new DataInputStream EXCEPTION HANDLING } int i = dataInput.readInt(); if (errno > 0) { System.err.println (“Error reading binary data from file”); return -1; } // The slide lacks space to close the file. Oh well. return i; 7 8 15-214 15-214 15-214 7 8 9 Compare to: Exceptions Exceptional control-flow in Java public static void test() { • Exceptions notify the caller of an exceptional try { System.out.println("Top"); try { circumstance (usually operation failure) int [] a = new int [10]; FileInputStream fileInput = new FileInputStream(filename); a[42] = 42; DataInput dataInput = new DataInputStream(fileInput); • Semantics System.out.println("Bottom"); int i = dataInput.readInt(); } catch (NegativeArraySizeException e) { fileInput.close(); System.out.println("Caught negative array size"); – An exception propagates up the function-call stack } return i; until main() is reached (terminates program) or } } catch (FileNotFoundException e) { System.out.println("Could not open file " + filename); until the exception is caught public static void main(String[] args) { return -1; try { } catch (IOException e) { • Sources of exceptions: System.out.println("Error reading binary data from file " test(); + filename); } catch (IndexOutOfBoundsException e) { – Programmatically throwing an exception return -1; System.out.println"("Caught index out of bounds"); } } – Exceptions thrown by the Java Virtual Machine } 15-214 15-214 15-214 10 11 12 2
Design choice: Checked and unchecked Java: The finally keyword The exception hierarchy in Java exceptions and return values Object • Unchecked exception: any subclass of • The finally block always runs after try/catch: Throwable RuntimeException – Indicates an error which is highly unlikely and/or Exception typically unrecoverable try { System.out.println("Top"); • Checked exception: any subclass of Exception . . . int[] a = new int[10]; a[2] = 2; that is not a subclass of RuntimeException RuntimeException IOException System.out.println("Bottom"); } catch (IndexOutOfBoundsException e) { – Indicates an error that every caller should be aware of … … ClassNotFoundExceptio System.out.println("Caught index out of bounds"); and explicitly decide to handle or pass on } finally { System.out.println("Finally got here"); • Return values (boolean, empty lists, null, etc): If NullPointerException EOFException } failure is common and expected possibility FileNotFoundException IndexOutOfBoundsException Design Principle: Explicit Interfaces (contracts) 15-214 15-214 15-214 13 14 15 Creating and throwing your own Benefits of exceptions Guidelines for using exceptions exceptions • Provide high-level summary of error and stack trace • Methods must declare any checked exceptions • Catch and handle all checked exceptions – Compare: core dumped in C they might throw – Unless there is no good way to do so… • Can’t forget to handle common failure modes • Use runtime exceptions for programming errors • If your class extends java.lang.Throwable you – Compare: using a flag or special return value • Can optionally recover from failure • Other good practices can throw it: – Compare: calling System.exit() – if (someErrorBlahBlahBlah) { – Do not catch an exception without (at least • Improve code structure somewhat) handling the error – throw new MyCustomException(“Blah blah – Separate routine operations from error-handling (see Cohesion) – When you throw an exception, describe the error blah”); • Allow consistent clean-up in both normal and – If you re-throw an exception, always include the – } exceptional operation original exception as the cause 15-214 15-214 15-214 16 17 18 3
Testing for presence of an exception import org.junit.*; import static org.junit.Assert.fail; public class Tests { @Test public void testSanityTest(){ try { openNonexistingFile(); fail("Expected exception"); } catch(IOException e) { } } @Test(expected = IOException.class) public void testSanityTestAlternative() { openNonexistingFile(); How to test behavior for missing routes file? } How to test failure to compute a route? } 20 21 15-214 15-214 15-214 19 20 21 Modular Protection Examples • Errors and bugs unavoidable, but exceptions should not • Printer crash should not corrupt entire system leak across modules (methods, classes), if possible – E.g., printer problem handled locally, logged, user • Good modules handle exceptional conditions locally informed – Local input validation and local exception handling where • Exception/infinite loop in Pine Simulation possible should not freeze GUI – Explicit interfaces with clear pre/post conditions – E.g., decouple simulation from UI – Explicitly documented and checked exceptions where exceptional conditions may propagate between modules • Error in shortest-path algorithm should not DESIGN PRINCIPLE: – Information hiding/encapsulation of critical code (likely corrupt graph bugs, likely exceptions) MODULAR PROTECTION – E.g., computation on immutable data structure 22 24 15-214 15-214 15-214 22 23 24 4
TESTING WITH COMPLEX ENVIRONMENTS What happens with incorrect entries in routes file? What happens if the routes file missing? Where and how to handle invalid routes? What happens when getEntities returns null? 25 26 27 15-214 15-214 15-214 25 26 27 Problems when testing (sub-)systems Example Example Tiramisu App • User interfaces and user interactions • 3rd party Route Planning • 3rd party Facebook apps for – Users click buttons, interpret output app for Android Android – Waiting/timing issues • User interface for • User interface for Android • Test data vs. real data Android • Testing against big infrastructure (databases, web • Internal • Internal services, …) computations computations • Testing with side effects (e.g., printing and ala HW1 ala HW2 mailing documents) • Backend with • Nondeterministic behavior • Backend with • Concurrency (more later in the semester) Facebook data PAT live data -> the test environment 15-214 15-214 15-214 28 29 30 5
Recommend
More recommend
