$11.6 CONTRACTING FOR SOFTWARE RELIABILITY 341 More precisely,it depends on what you want.You may decide to treat assertions purely as comments,with no effect on the software's execution;then a run-time assertion violation will remain undetected.But it is also possible to use assertions to check that everything goes according to plan;then during execution the environment will automatically monitor that all assertions hold when they should,and if one does not it will trigger an exception,usually terminating execution and printing a message indicating clearly what happened.(It is also possible to include an exception handling clause that will try to recover from the exception and continue execution;exception handling is discussed in detail in the next chapter.)To specify the policy that you want-no assertion checking. or assertion monitoring at one of various possible levels-you will use a compilation option,which you can set separately for each class. See"Monitoring The full details of run-time assertion monitoring do appear later in this chapter.But assertions at rim it would be a mistake to attach too much importance to this aspect at this stage (one of the time”,page393. reasons why you were warned earlier not to think too much about the C notion of assertion if that has been your only exposure to the concept).Other aspects of assertions demand our attention first.We have only started to see assertions as a technique to help us get our software right in the first place;we still have much to discover of their methodological role as built-in guardians ofreliability.The question of what happens if we do fail (in particular if an assertion,in spite of all our efforts,is not satisfied at some execution instant)is important too,but only after we have done all we could to prevent it from arising. So(although it is never bad to think ahead)you do not need at this point to be too preoccupied by such questions as the possible performance penalty implied by the old construct.Must the run-time system preserve values before we start a routine,just to be able to evaluate an old expression appearing in the postcondition?It depends:in some circumstances(for example testing and debugging)it will indeed be useful to evaluate assertions;in others(for example production runs of fully validated systems)you can treat them as mere annotations to the software text. All that counts for the next few sections is the methodological contribution of assertions,and of the associated method of Design by Contract:as a conceptual tool for analysis,design,implementation and documentation,helping us to build software in which reliability is built-in,rather than achieved or attempted after the fact through debugging;in Mills's terms,enabling us to build correct programs and know it. 11.6 CONTRACTING FOR SOFTWARE RELIABILITY Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers. Rights and obligations By associating clauses require pre and ensure post with a routine r,the class tells its clients: "If you promise to call r with pre satisfied then I,in return,promise to deliver a final state in which post is satisfied."§11.6 CONTRACTING FOR SOFTWARE RELIABILITY 341 More precisely, it depends on what you want. You may decide to treat assertions purely as comments, with no effect on the software’s execution; then a run-time assertion violation will remain undetected. But it is also possible to use assertions to check that everything goes according to plan; then during execution the environment will automatically monitor that all assertions hold when they should, and if one does not it will trigger an exception, usually terminating execution and printing a message indicating clearly what happened. (It is also possible to include an exception handling clause that will try to recover from the exception and continue execution; exception handling is discussed in detail in the next chapter.) To specify the policy that you want — no assertion checking, or assertion monitoring at one of various possible levels — you will use a compilation option, which you can set separately for each class. The full details of run-time assertion monitoring do appear later in this chapter. But it would be a mistake to attach too much importance to this aspect at this stage (one of the reasons why you were warned earlier not to think too much about the C notion of assertion if that has been your only exposure to the concept). Other aspects of assertions demand our attention first. We have only started to see assertions as a technique to help us get our software right in the first place; we still have much to discover of their methodological role as built-in guardians of reliability. The question of what happens if we do fail (in particular if an assertion, in spite of all our efforts, is not satisfied at some execution instant) is important too, but only after we have done all we could to prevent it from arising. So (although it is never bad to think ahead) you do not need at this point to be too preoccupied by such questions as the possible performance penalty implied by the old construct. Must the run-time system preserve values before we start a routine, just to be able to evaluate an old expression appearing in the postcondition? It depends: in some circumstances (for example testing and debugging) it will indeed be useful to evaluate assertions; in others (for example production runs of fully validated systems) you can treat them as mere annotations to the software text. All that counts for the next few sections is the methodological contribution of assertions, and of the associated method of Design by Contract: as a conceptual tool for analysis, design, implementation and documentation, helping us to build software in which reliability is built-in, rather than achieved or attempted after the fact through debugging; in Mills’s terms, enabling us to build correct programs and know it. 11.6 CONTRACTING FOR SOFTWARE RELIABILITY Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers. Rights and obligations By associating clauses require pre and ensure post with a routine r, the class tells its clients: “If you promise to call r with pre satisfied then I, in return, promise to deliver a final state in which post is satisfied.” See “Monitoring assertions at run time”, page 393