{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Chapter12 - 12 When the contract is broken exception...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
12 When the contract is broken: exception handling L ike 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).
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
WHEN THE CONTRACT IS BROKEN: EXCEPTION HANDLING § 12.1 412 Such a case will be called a failure. The discussion will use the phrase “routine failure”, or just “failure”, as an abbreviation for “failure of a routine call”. Of course what succeeds or fails is not a routine (an element of the software text) but one particular call to that routine at run time. Exceptions From the notion of failure we can derive a precise definition of exceptions. A routine fails because of some specific event (arithmetic overflow, assertion violation ) that interrupts its execution. Such an event is an exception. Often an exception will cause failure of the routine. But you can prevent this from occurring by writing the routine so that it will catch the exception and try to restore a state from which the computation will proceed. This is the reason why failure and exception are
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}