exception to 17
This commit is contained in:
@@ -1,14 +1,14 @@
|
||||
# Lecture 24 --- C++ Exceptions
|
||||
# Lecture 17 --- C++ Exceptions
|
||||
|
||||
## Today’s Lecture
|
||||
|
||||
- HW9 Discussion
|
||||
- HW7 Discussion
|
||||
- Error handling strategies
|
||||
- Basic exception mechanisms: try/throw/catch
|
||||
- Functions & exceptions, constructors & exceptions
|
||||
- STL exceptions
|
||||
|
||||
## 24.1 Error Handling Strategy A: Optimism (a.k.a. Na¨ıvet´e or Denial)
|
||||
## 17.1 Error Handling Strategy A: Optimism (a.k.a. Na¨ıvet´e or Denial)
|
||||
|
||||
- Assume there are no errors. Command line arguments will always be proper, any specified files will always be available for read/write, the data in the files will be formatted correctly, numerical calculations will not attempt to divide by zero, etc.
|
||||
|
||||
@@ -19,7 +19,7 @@ double answer = numer / denom;
|
||||
- For small programs, for short term use, by a single programmer, where the input is well known and controlled, this may not be a disaster (and is often fastest to develop and thus a good choice).
|
||||
- But for large programs, this code will be challenging to maintain. It can be difficult to pinpoint the source of an error. The symptom of a problem (if noticed at all) may be many steps removed from the source. The software system maintainer must be familiar with the assumptions of the code (which is difficult if there is a ton of code, the code was written some time ago, by someone else, or is not sufficiently commented... or all of the above!).
|
||||
|
||||
## 24.2 Error Handling Strategy B: Plan for the Worst Case (a.k.a. Paranoia)
|
||||
## 17.2 Error Handling Strategy B: Plan for the Worst Case (a.k.a. Paranoia)
|
||||
|
||||
- Anticipate every mistake or source of error (or as many as you can think of). Write lots of if statements everywhere there may be a problem. Write code for what to do instead, print out error messages, and/or exit when nothing seems reasonable.
|
||||
|
||||
@@ -44,7 +44,7 @@ error along. (This is messy to code and all that error checking has performance
|
||||
- Creating a comprehensive test suite (yes, error checking/handling code must be tested too!) that exercises all
|
||||
the error cases is extremely time consuming, and some error situations are very difficult to produce.
|
||||
|
||||
## 24.3 Error Handling Strategy C: If/When It Happens We’ll Fix It (a.k.a. Procrastination)
|
||||
## 17.3 Error Handling Strategy C: If/When It Happens We’ll Fix It (a.k.a. Procrastination)
|
||||
|
||||
- Again, anticipate everything that might go wrong and just call assert in lots of places. This can be somewhat less work than the previous option (we don’t need to decide what to do if the error happens, the program just exits immediately).
|
||||
|
||||
@@ -59,7 +59,7 @@ handle special cases and errors.
|
||||
- However, the use of assertions is generally frowned upon in real-world production code (users don’t like to receive seemingly arbitrary & total system failures, especially when they paid for the software!).
|
||||
- Once you have completed testing & debugging, and are fairly confident that the likely error cases are appropriately handled, then the gcc compile flag -DNDEBUG flag can be used to remove all remaining assert statements before compiling the code (conveniently removing any performance overhead for assert checking).
|
||||
|
||||
## 24.4 Error Handling Strategy D: The Elegant Industrial-Strength Solution
|
||||
## 17.4 Error Handling Strategy D: The Elegant Industrial-Strength Solution
|
||||
|
||||
- Use exceptions. Somewhat similar to Strategy B, but in practice, code written using exceptions results in more efficient code (and less overall code!) and that code is less prone to programming mistakes.
|
||||
|
||||
@@ -78,7 +78,7 @@ catch (std::string &error) {
|
||||
}
|
||||
```
|
||||
|
||||
## 24.5 Basic Exception Mechanisms: Throw
|
||||
## 17.5 Basic Exception Mechanisms: Throw
|
||||
|
||||
- When you detect an error, throw an exception. Some examples:
|
||||
|
||||
@@ -90,7 +90,7 @@ throw Foo(2,5);
|
||||
- You can throw a value of any type (e.g., int, std::string, an instance of a custom class, etc.)
|
||||
- When the throw statement is triggered, the rest of that block of code is abandoned
|
||||
|
||||
## 24.6 Basic Exception Mechanisms: Try/Catch
|
||||
## 17.6 Basic Exception Mechanisms: Try/Catch
|
||||
|
||||
- If you suspect that a fragment of code you are about to execute may throw an exception and you want to prevent the program from crashing, you should wrap that fragment within a try/catch block:
|
||||
|
||||
@@ -120,7 +120,7 @@ terminate called after throwing an instance of 'bool'
|
||||
Abort trap
|
||||
```
|
||||
|
||||
## 24.7 Basic Exception Mechanisms: Functions
|
||||
## 17.7 Basic Exception Mechanisms: Functions
|
||||
|
||||
If a function you are writing might throw an exception, you can specify the type of exception(s) in the prototype.
|
||||
|
||||
@@ -149,7 +149,7 @@ not listed, the program will terminate immediately (it can’t be caught by any
|
||||
- If you don’t use the throw syntax in the prototype, the function may throw exceptions of any type, and they
|
||||
may be caught by an appropriate try/catch block.
|
||||
|
||||
## 24.8 Comparing Method B (explicit if tests) to Method D (exceptions)
|
||||
## 17.8 Comparing Method B (explicit if tests) to Method D (exceptions)
|
||||
|
||||
Here’s code using exceptions to sort a collection of lines by slope:
|
||||
|
||||
@@ -203,7 +203,7 @@ Specifically note the behavior if one of the lines has infinite slope (a vertica
|
||||
- Exercise: Rewrite this code to have the same behavior but without exceptions. Try to preserve the overall
|
||||
structure of the code as much as possible. (Hmm... it’s messy!)
|
||||
|
||||
## 24.9 STL exception Class
|
||||
## 17.9 STL exception Class
|
||||
|
||||
STL provides a base class std::exception in the <exception> header file. You can derive your own exception
|
||||
type from the exception class, and overwrite the what() member function
|
||||
@@ -236,7 +236,7 @@ bad typeid thrown by typeid
|
||||
ios base::failure thrown by functions in the iostream library
|
||||
```
|
||||
|
||||
## 24.10 Exceptions & Constructors
|
||||
## 17.10 Exceptions & Constructors
|
||||
|
||||
The only way for a constructor to fail is to throw an exception.
|
||||
- A common reason that a constructor must fail is due to a failure to allocate memory. If the system cannot
|
||||
@@ -253,6 +253,6 @@ catch (std::exception& e) {
|
||||
- It can also be useful to have the constructor for a custom class throw a descriptive exception if the arguments
|
||||
are invalid in some way.
|
||||
|
||||
## 23.10 Leetcode Exercises
|
||||
## 17.11 Leetcode Exercises
|
||||
|
||||
- [Leetcode problem 7: Reverse Integer](https://leetcode.com/problems/reverse-integer/). Solution: [p7_reverse_integers.cpp](../../leetcode/p7_reverse_integers.cpp).
|
||||
Reference in New Issue
Block a user