41 ;;Quote: defensive programming attempts to catch all problems; often redundant checks; increases complexity

41 ;;Quote: software elements should be implementations of well-understood specifications, not as arbitrary executable texts

41 ;;Quote: a legal contract specifies how much the contractor will do and how little is acceptable to the client; protects both sides

42 ;;Quote: assertions define the contract between caller and called routines

42+;;Quote: class invariants apply to all routines, while pre- and post-conditions apply to individual routines

43 ;;Quote: Eiffel's rescue clause handles an error by restoring the class invariant, and if resumption, the routine's precondition; unlike recovery blocks

44 ;;Quote: defensive programming not necessary with Eiffel since all preconditions are guaranteed by the client

45 ;;Quote: Eiffel assertions are boolean expressions (includes function calls); no side-effects or errors

46 ;;Quote: Eiffel's 'short' command documents a class by extracting parameters, documentation, pre- and post-conditions

46 ;;Quote: for documenting inherited classes, first flatten the class before using Eiffel's 'short' command

46 ;;Quote: violations of assertions indicate bugs; can control the level for checking assertions

48 ;;Quote: if redeclare an inherited routine, can weaken its precondition or strengthen its postcondition

49 ;;Quote: failure of a routine occurs when it can't fulfill its specification; use rescue clauses for resumption or organized panic

49+;;Quote: an exception occurs when a strategy for fulfilling a routine's contract fails