10-exceptions.student - Last Time Arguments to programs...

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

View Full Document Right Arrow Icon
Last Time: * Arguments to programs: argc and argv * Templates---generalizing across types Today: * Exceptions Motivation for exceptions Exception handling mechanism C++ usage Administrative: * Project Three released. * Read notes for File I/O (useful for P3) * Three things to remember about P3 - START EARLY - START EARLY - START EARLY Motivation Once or twice, we've talked about partial functions. A partial function does not produce meaningful results for all possible values of its inputs. 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. A REQUIRES specification given in the function declaration lists the conditions, if any, that the function inputs must satisfy in order for the function to deliver meaningful results. This is like a contract between the writer of the function and the writer of the call to the function -- as long as both parties honor the contract, the function will always produce those meaningful results. If either party reneges, all bets are off. 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. 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! 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. We need some way to define a legitimate outcome for (illegitimate) inputs. There are three general strategies for this.
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
1. "It's my problem!" Try to "fix" things and continue execution. Here we coerce legitimate inputs from illegitimate ones, either 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. Likewise, list_first() probably shouldn't just make up an answer if passed an empty list. 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.

{[ snackBarMessage ]}

Page1 / 7

10-exceptions.student - Last Time Arguments to programs...

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