In this lesson, our instructor Alvin Sylvain goes through an introduction on exception handling. He discusses what happens when something goes wrong, different error checking methods, exception handling, basic syntax, example exception, throw exception, character string exceptions, derive from 'exception' class, exception derivation, and exceptions not derived from exception.
Modify your program that implements the “Auto” class.
Analog systems are not perfect. If the application is receiving input from an actual mechanical pedal, it is possible that in a desired range between, say, 0.0 and 100.0, it may occasionally be -0.5, which may be within the acceptable margin for error. If the input is within this margin, assume it is 0.0.
If the input is more negative than your margin of error, throw an exception.
For now, just throw a character string literal type
Throw different strings based on just how far from the margin of error the input is, e.g., if it’s less than -1.5 you could print,
“Pedal pressure outside of acceptable margin”,
then if it’s less than -10.0 print,
“Pedal pressure is in need of manual adjustment”,
then if it’s -100.0 or worse print,
“PEDAL IS BROKEN! Time to buy a new one.”
You don’t want the program to simply crash in such an event, so make sure the code that sets the pedal pressure is within a try-catch block.
Print the text of the exception in the catch portion.
Extra: output each exception to a log file that can be reviewed later.
Test your changes by providing various arbitrary values at different points in your loop, including values within your margin of error, and values that should cause each of the exceptions to be thrown.
Modify the program to read the pedal pressures from a file. This should drastically shorten your testing program, and you can test numerous scenarios without recompiling.
Open the file
Loop through each record until end-of-file, and read a character that will specify “A” for acceleration or “B” for brake, followed by the pressure to be applied
For each record, set the appropriate pedal pressure in your “try-catch” block, advance the time, print the results
Close the file
Make sure you create enough test scenarios to exercise each exception.
Change the exception to throw an integer instead of a character string literal. This allows for simpler testing against the exception (i.e., the integer “10” can always mean, “Manual Adjustment Needed”, instead of comparing the text. You’ll be free to change the message, such as for language translation.)
Decide what action should be taken within the “catch” block for each integer that might be thrown
Just print a message? (e.g., for the exceptions that aren’t severe)
Print a friendly message then halt the program gracefully? (e.g., for severe exceptions)
Think about what would you want to occur if a similar program was actually implemented in a real race car?
Create your own hugely overblown “Exception” class that has these attributes:
A code that can be looked up in a database for the text of the message, and what the user should do about it (you don’t need to create this database for this class) – e.g., a negative pedal pressure code could be “NP”.
A text message in English that briefly describes the error (the database can worry over other languages, should that be required)
A code that can be looked up in a database that indicates which module in the program is throwing this exception, which can tell the maintainer where to begin looking for the problem – e.g., the methods in the “Auto” class that throw exceptions can use the code, “AU”.
A severity code, e.g.,
0 – Information only; not really a problem but may be useful
10 – Warning; is not serious but may mask other problems
100 – Error; results may be wrong but processing will continue
1000 – Serious error; caller should attempt immediate graceful halt
Print the details in the constructor, so that neither thrower nor catcher needs to worry about logging the exceptions that may occur.
Extra: output the details to a log file for later review. Your issue here will be deciding how to use a file globally, e.g., whether or not to open for “append” to a file with a hard-coded filename.
Of course, test this by adding it to your “Auto” program that you have been slaving over all this time!
Lecture Slides are screen-captured images of important points in the lecture. Students can download and print out these lecture slide images to do practice problems as well as take notes while watching the lecture.