Error Management with Design Contracts

1. Error Management with Design Contracts Eivind J. Nordby, Martin Blom, Anna Brunstrom Computer Science, Karlstad University Presented at SERP '01 Ronneby

2. Q & A • How can code complexity be reduced? • There is a paranoia to handle all kinds of errors in all possible situations • referred to as defensive programming • A lot of code complexity is due to error management • Distinguish between different kinds of errors • Reduce error management where it is not needed SERP '01 Ronneby 2

3. Disposition • We present a development strategy and a case study • based on design contracts • for error management • in software development • External and internal errors • Weak and strong contracts • Liskov (LSP) and Meyer (ARR) • The strategy • The case study SERP '01 Ronneby 3

4. External and internal interfaces • A system part exposes interfaces • external or internal System part Externalinterface Internalinterface Supplier SERP '01 Ronneby 4

5. External and internal errors • on a per use basis, varying from case to case • on a permanent basis, consistent until the software is corrected • External errors • commited by end users or external systems • cause violation of external interfaces • Internal errors • committed by developers • result in faults in the software • cause violation of internal interfaces SERP '01 Ronneby 5

6. Client Supplier Precondition not met Correct Correct Postcondition not met Postcondition met ! ? QIQO GIGO result undefined Design contracts: Basic principles Client Supplier Precondition met SERP '01 Ronneby 6

7. Strong contract not qualified qualified Qualified input required Client responsibility Weak vs. strong contracts Weak contract not OK OK Any input accepted failure success Double responsibility SERP '01 Ronneby 7

8. Comparison • Weak contracts • are needed where a correct call cannot be assured • providing an open-ended exit • Strong contracts • simplifies the solution by reducing complexity • simplifies error detection by allocating responsibilities • reducing the number of faults and saving time • reducing the number of faults and saving time • Strong contracts should be used whenever possible SERP '01 Ronneby 8

9. Correspondence contracts  errors • External errors • wrong input should be tolerated • the user should be informed • handled by weak contracts • Internal errors • faults resulting from internal errors should be detected • the fault should be corrected before proceeding • handled by strong contracts SERP '01 Ronneby 9

10. Liskov's Substitution Principle (LSP) • If • for all o1 • there exists an o2 • when P depends on T • o1 can replace o2 • behavior of P is unchanged • Then • S is a subtype of T o2:T defined in terms of :P o1 replaces o2 o1:S SERP '01 Ronneby 10

11. assures expects preT postT Needed: preT preS Needed: postS postT preS postS S::f() Meyer's Assertion Redeclaration Rule (ARR) expects assures preT postT T::f() SERP '01 Ronneby 11

12. Liskov (LSP) and Meyer (ARR) combined • When a routine is redefined in a subclass:if the redefined • precondition is weaker than or equal to • postcondition is stronger than or equal tothe original one • then • the clients of the class are not affected  the subclass is a Liskov subtype SERP '01 Ronneby 12

13. Weak and strong contracts • Definition • a redefined contract is weaker than the original one if it satisfied the Assertion Redeclaration Rule • Consequence • weakening a contract defines a Liskov subtype of the module • Generalization • not only for classes • for modules in general SERP '01 Ronneby 13

14. The strategy • Start with strong contracts • reduce internal errors • Change to weak contracts when error free • accommodate external errors • Add handling in the client • of the added postconditions in the weakened contract SERP '01 Ronneby 14

15. Architecture of the Case Study SERP '01 Ronneby 15

16. Functionality of the Case Study • System access from wap or web browser • End users maintain dynamic, personalized menus • Most common telecom services or Internet links • Editing options • Move, delete, edit menu options • Create, delete, link menus • Operation options • Normal hyperlink operation SERP '01 Ronneby 16

17. Size of the Case Study • Whole system • 10 persons, 6 months • 16,000 lines of code, • including comments and blank lines • Business logic module • 2 persons • 6,000 lines of code • 17 classes, 70 operations • including internal support operations SERP '01 Ronneby 17

18. Contracts of the Case Study • Strong contracts were applied in the Business Logic interface • Example from class Menu • MenuItem getItem(itemId) • Called from a user menu display • Precondition: the item exists in the menu • Postcondition: the details about the menu item are returned SERP '01 Ronneby 18

19. Implementation of getItem(itemId) • In class Menu loop from first item compare current item with parameter until parameter item found return the details of the current item • Exploiting the strong contracts • precondition  loop runs at least once • precondition  item found before end of list • Contract violation detection • Java’s built-in runtime control • “Index out of bounds”, “Null pointer” exceptions SERP '01 Ronneby 19

20. Experiences from using Strong Contracts • Implementation of Business Logic module • Focus on design and correctness • no development time spent on handling illegal calls • Quick and virtually error free implementation • Programmers not used to strong contracts • Initial contract violations and crashes • Subsequent disciplined use and • Few faults in the business logic communication • Stable failure profile • Fault were detected early, no late surprises SERP '01 Ronneby 20

21. Weakening the Contracts • Some operations were subject to illegal calls • An URL with function parameters could be edited manually on the web browser • The contracts of 16 operations were weakened • MenuItem getItem(itemId) • Precondition: true • Postcondition: if the item exists in the menu, then the details about the menu item has been returned, else an exception has been thrown SERP '01 Ronneby 21

22. Experiences from weakening the Contracts • Modification in the Business Logic • was easy • caused no new faults • Adaptation in the client software • to take advantage of the weaker contracts for robustness • was easy • caused few new faults SERP '01 Ronneby 22

23. Conclusions • Starting out with strong contracts • allows initial focus on correctness • improves fault characteristics • allows later weakening without affecting client code • Passing to weak contracts • on selected operations exposed to external errors • adds system robustness as a separate concern • is easy and cost effective SERP '01 Ronneby 23

24. Thank you for your attention!Are there any questions? Eivind J. Nordby, Martin Blom, Anna Brunstrom Karlstad University, Computer Science, 651 88 Karlstad{Martin.Blom, Eivind.Nordby, Anna.Brunstrom}@kau.se

25. Failures, faults and errors • Failure = the product behaving incorrectly • Fault = defect in the product • May result in a failure during execution • Error = wrong human behavior • Error from a developer • should be avoided • may produce faults in the software • Error from the end user • must be tolerated and taken care of • the software should protect the system integrity SERP '01 Ronneby 25

26. Liskov (LSP) and Meyer (ARR) • Liskov only requires this to be true in the cases covered by the original routine • that is when the original precondition is satisfied • Strong vs. weak contracts • preS preW: qualified input true • preS : postW  postS: postW and success = postS SERP '01 Ronneby 26

27. Summary of the principles • Strong contracts are suited for detecting faults resulting from internal errors • promote fault free software • A strong contract may be LSP substituted by a weaker one • will not affect client software • Weak contracts are suited for tolerating external errors • promote robust external interfaces SERP '01 Ronneby 27