Sign In | Subscribe
Start learning today, and be successful in your academic & professional career. Start Today!
Loading video...
This is a quick preview of the lesson. For full access, please Log In or Sign up.
For more information, please see full course syllabus of Intermediate C++
  • Discussion

  • Study Guides

  • Download Lecture Slides

  • Table of Contents

  • Related Services

Bookmark and Share

Start Learning Now

Our free lessons will get you started (Adobe Flash® required).
Get immediate access to our entire library.

Sign up for Educator.com

Membership Overview

  • Unlimited access to our entire library of courses.
  • Search and jump to exactly what you want to learn.
  • *Ask questions and get answers from the community and our teachers!
  • Practice questions with step-by-step solutions.
  • Download lesson files for programming and software training practice.
  • Track your course viewing progress.
  • Download lecture slides for taking notes.
  • Learn at your own pace... anytime, anywhere!

Exception Handling

  • 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
      • 10000 – Disastrous error! Abandon ship! Abandon ship!
    • 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!

Exception Handling

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.

  1. Intro
    • Overview
      • Something Went Wrong! Now What?
      • Different Error Checking Methods
      • Traditional Error Checking
      • Exception Handling
      • Basic Syntax
      • Example Exception
      • Throw Exception
      • Character String Exceptions
      • Derive From 'Exception' Class
      • Exception Derivation Example
        • Adding 'Throw()' Keyword to Prototype
        • Exceptions Not Derived From 'Exception'
          • Don’t Rely on System Exceptions!
          • Exceptional!
            • Intro 0:00
            • Overview 0:11
            • Something Went Wrong! Now What? 6:05
              • Data Must Always be Validated
              • Many Operations Will Validate Input to Make Sure No Mistakes Were Made
              • Many Check the External Environment
              • Many Don’t Check But App Can Still Crash
            • Different Error Checking Methods 11:38
              • Traditional Method
              • Exception Handlin
              • Lazy Way
            • Traditional Error Checking 16:08
              • Example: Return Code, Simply 'if'
              • Example: Output Parameter
            • Exception Handling 20:01
              • 'Try' Block
              • 'Catch All' Block
              • No 'Finally' Block
              • 'System Errors'
            • Basic Syntax 23:12
              • Code to Throw an Exception
              • Code to Handle an Exception
            • Example Exception 26:51
              • Run This Program Fragment, It Will Crash
              • Run This One, The Error is Controlled
            • Throw Exception 30:51
              • Can 'Throw' An Exception If Error Conditions Found
              • Basic Example' 'int' Exceptions
            • Character String Exceptions 36:16
              • Exception Can Be Any Type, But a Character String Can be Informative in Simple Cases
              • Not Good for More Than Simple Situations
            • Derive From 'Exception' Class 38:34
              • When You Don’t Care Exactly Which Sub-Class of 'Exception' Can Be Thrown
              • When Each Sub-Class Handled Differently
            • Exception Derivation Example 41:28
            • Adding 'Throw()' Keyword to Prototype 45:32
              • Promises to Compiler What Kind of Exceptions the Function or Method Might Throw
              • Leave the Keyword Off
              • Leave the Parameter List Empty
              • Exception Can Not Be Caught With a Type-Specific Handler
            • Exceptions Not Derived From 'Exception' 49:11
            • Don’t Rely on System Exceptions! 54:06
              • Certain System Operations Don't Throw an Exception in a Platform-Independent Manner
              • Examples
              • Your Own Code Should Test for the Conditions That Might Lead to Uncatchable Exceptions
            • Exceptional! 57:30