diff --git a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki index bc603f89..d9edb63f 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki @@ -38,7 +38,7 @@ In addition to preconditions and postconditions, contract clauses include '''cla ==Expressing assertions== -Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see [[ET: Other Mechanisms#Instructions|"Instructions"]] ): loop invariants and variants, check instructions. +Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see "[[ET: Instructions|Instructions]]" ): loop invariants and variants, check instructions. Here is a partial update of class ACCOUNT with more assertions: @@ -135,7 +135,7 @@ Note in this respect that guaranteeing a precondition does not necessarily mean, possibly with an else part. But if the context of the call, in the client's code, implies that n is positive -- perhaps because some preceding call set it to the sum of two squares -- then there is no need for an if or similar construct. -{{note|In such a case, a check instruction as introduced later ( [[ET: Other Mechanisms#Instructions|"Instructions"]] ) is recommended if the reason for omitting the test is non-trivial. }} +{{note|In such a case, a check instruction as introduced later ( "[[ET: Instructions|Instructions]]" ) is recommended if the reason for omitting the test is non-trivial. }} ==Using contracts for built-in reliability==