12 When the contract is broken: exception handling ikeitrit is no use pretending:in spite of all static precautions,some unexpected and undesired event will sooner or later occur while one of your systems is executing.This is known as an exception and you must be prepared to deal with it. 12.1 BASIC CONCEPTS OF EXCEPTION HANDLING The literature on exception handling is often not very precise about what really constitutes an exception.One of the consequences is that the exception mechanisms present in such programming languages as PL/I and Ada are often misused:instead of being reserved for truly abnormal cases,they end up serving as inter-routine goto instructions,violating the principle of Modular Protection. Fortunately,the Design by Contract theory introduced in the preceding chapter provides a good framework for defining precisely the concepts involved. Failures Informally,an exception is an abnommal event that disrupts the execution of a system.To obtain a more rigorous definition,it is useful to concentrate first on a more elementary concept,failure,which follows directly from the contract idea A routine is not just some arbitrary sequence of instructions but the implementation of a certain specification-the routine's contract.Any call must terminate in a state that satisfies the precondition and the class invariant.There is also an implicit clause in the contract:that the routine must not have caused an abnormal operating system signal, resulting for example from memory exhaustion or arithmetic overflow and interrupting the normal flow of control in the system's execution. It must refrain from causing such events,but of course not everything in life is what it must be,and we may expect that once in a while a routine call will be unable to satisfy its contract-triggering an abnormal signal,producing a final state that violates the postcondition or the invariant,or calling another routine in a state that does not satisfy that routine's precondition(assuming run-time assertion monitoring in the last two cases).12 When the contract is broken: exception handling Like it or not, it is no use pretending: in spite of all static precautions, some unexpected and undesired event will sooner or later occur while one of your systems is executing. This is known as an exception and you must be prepared to deal with it. 12.1 BASIC CONCEPTS OF EXCEPTION HANDLING The literature on exception handling is often not very precise about what really constitutes an exception. One of the consequences is that the exception mechanisms present in such programming languages as PL/I and Ada are often misused: instead of being reserved for truly abnormal cases, they end up serving as inter-routine goto instructions, violating the principle of Modular Protection. Fortunately, the Design by Contract theory introduced in the preceding chapter provides a good framework for defining precisely the concepts involved. Failures Informally, an exception is an abnormal event that disrupts the execution of a system. To obtain a more rigorous definition, it is useful to concentrate first on a more elementary concept, failure, which follows directly from the contract idea. A routine is not just some arbitrary sequence of instructions but the implementation of a certain specification — the routine’s contract. Any call must terminate in a state that satisfies the precondition and the class invariant. There is also an implicit clause in the contract: that the routine must not have caused an abnormal operating system signal, resulting for example from memory exhaustion or arithmetic overflow and interrupting the normal flow of control in the system’s execution. It must refrain from causing such events, but of course not everything in life is what it must be, and we may expect that once in a while a routine call will be unable to satisfy its contract — triggering an abnormal signal, producing a final state that violates the postcondition or the invariant, or calling another routine in a state that does not satisfy that routine’s precondition (assuming run-time assertion monitoring in the last two cases)