10-exceptions.student

10-exceptions.student - Today we'll cover exceptions a...

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

View Full Document Right Arrow Icon
Sheet1 Page 1 Today we'll cover exceptions, a means of recognizing and handling unusual conditions in your program at runtime. Outline: . Motivation . Exception handling mechanism . C++ usage Motivation Once or twice, we've talked about partial functions. And we have seen one particular way of preventing a partial function from receiving inputs for which it cannot deliver meaningful results: the REQUIRES specification. But there is a problem with REQUIRES specifications, which we have alluded to before. They are implemented as comments, and thus have no power to enforce the specification. It is therefore easy to pass parameters in violation of the specification. Even in the presence of REQUIRES specifications, partial functions are icky, since they depend on the caller being "correct", which we now know is dubious at best. So let's look at another way of ensuring correct inputs, namely by runtime checking. In other words, if we can't guarantee formally (that is, via a specification) that the inputs are correct, maybe we can guarantee this by checking the inputs explicitly, before using them, in our program. However, a Nice Thing about a specification is that we can assume it will be honored by the caller -- this means we do not need to check for invalid inputs, because the contract says they will never occur. In particular it means we never have to figure out what to do if we are passed those incorrect inputs! But when checking at runtime, we do. We need some way to define a legitimate outcome for (illegitimate) inputs. There are three general strategies for this. 1. "It's my problem!" Try to "fix" things and continue execution. Here we coerce legitimate inputs from illegitimate ones, either
Background image of page 1

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

View Full DocumentRight Arrow Icon
Sheet1 Page 2 modifying them or returning default outputs that make sense in the context in which the function is defined. For example, list_rest() could return an empty list if presented with an empty list, if everyone involved agrees that this is the right thing to do. Such behavior must be explained in the specification! However, this strategy fails whenever the function cannot implement its specification with the given inputs. For example, what is factorial to do if it is passed a negative integer? Factorial is simply undefined for negative numbers, and trying to define it changes the rules of math. 2. "I Give up!"
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.

This note was uploaded on 01/28/2010 for the course EECS 280 taught by Professor Noble during the Winter '08 term at University of Michigan.

Page1 / 12

10-exceptions.student - Today we'll cover exceptions a...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online