9.x — Chapter 9 summary and quiz

In this chapter, you learned about error detection and handling - essential skills for writing robust, reliable C++ programs. Let's review the key concepts and test your understanding.

Chapter 9 summary

Testing your code (9.1)

• Software testing verifies that programs work correctly under various conditions
• Manual testing involves running programs yourself and checking results
• Automated testing uses code to test other code systematically
• Test cases should include normal cases, boundary cases, and error cases
• Test-Driven Development (TDD) involves writing tests before implementing functions
• Regression testing ensures fixes don't break existing functionality

Code coverage (9.2)

• Code coverage measures how much of your source code is executed during testing
• Line coverage tracks which lines of code have been executed
• Branch coverage measures whether both true and false branches of conditions are tested
• Function coverage tracks which functions have been called
• High coverage doesn't guarantee correctness - you need thoughtful test design
• Aim for 80-100% line coverage and 70-90% branch coverage

Common semantic errors (9.3)

• Semantic errors are logical mistakes that compile but produce incorrect results
• Off-by-one errors involve incorrect loop bounds or array indices
• Infinite loops occur when loop conditions never become false
• Uninitialized variables contain garbage values and cause unpredictable behavior
• Assignment vs. comparison errors use = instead of == in conditions
• Precedence errors misunderstand operator evaluation order
• Prevention strategies include meaningful names, constants, and proper initialization

Detecting and handling errors (9.4)

• Error detection identifies when something goes wrong in your program
• Error handling decides what to do when errors are detected
• Common approaches include return error codes, output parameters, and early returns
• Defensive programming validates all inputs and checks preconditions
• Error logging helps track problems for debugging and monitoring
• Always provide clear, actionable error messages

std::cin and handling invalid input (9.5)

• Stream states (good, fail, bad, eof) indicate input operation status
• Use std::cin.clear() to reset error flags after failed input
• Use std::cin.ignore() to skip invalid input in the buffer
• Always validate user input before using it in calculations
• Create robust input functions that retry on invalid input
• Consider using std::getline() with string parsing for complex validation

Assert and static_assert (9.6)

• assert() checks conditions at runtime and terminates on failure
• static_assert checks conditions at compile time and prevents compilation
• Assertions are debugging tools for catching programming errors
• Use assertions for preconditions, postconditions, and invariants
• Don't use assertions for expected runtime conditions or user errors
• Assertions can be disabled in release builds with NDEBUG

Key concepts review

Error types

// Syntax error - prevents compilation
int x = 5  // Missing semicolon

// Semantic error - compiles but wrong logic
bool isEven(int n) { return n % 2 == 1; }  // Should be == 0

// Runtime error - crashes during execution
int result = 10 / 0;  // Division by zero

// Logic error - wrong algorithm
int max = (a > b) ? b : a;  // Returns minimum, not maximum

Input validation pattern

#include <iostream>
#include <limits>

int getValidInteger()
{
    int number;
    while (true)
    {
        std::cout << "Enter an integer: ";
        if (std::cin >> number)
        {
            return number;  // Success
        }
        else
        {
            std::cout << "Invalid input. Try again." << std::endl;
            std::cin.clear();  // Clear error state
            std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');  // Skip bad input
        }
    }
}

Testing pattern

bool testFunction()
{
    // Test normal cases
    if (add(2, 3) != 5) return false;
    
    // Test edge cases
    if (add(0, 0) != 0) return false;
    
    // Test boundary cases
    if (add(-1, 1) != 0) return false;
    
    return true;  // All tests passed
}

Assertion pattern

#include <cassert>

int divide(int a, int b)
{
    assert(b != 0 && "Division by zero");  // Programming error check
    return a / b;
}

template<int N>
class FixedArray
{
    static_assert(N > 0, "Array size must be positive");  // Compile-time check
    // ...
};

Best practices summary

1. Test early and often - Write tests as you develop code
2. Validate all inputs - Never trust user input or external data
3. Use meaningful error messages - Help users and developers understand problems
4. Handle errors gracefully - Don't crash, provide alternatives when possible
5. Use assertions for debugging - Catch programming errors during development
6. Initialize all variables - Prevent undefined behavior from garbage values
7. Check preconditions and postconditions - Verify function contracts
8. Use static analysis tools - Let compilers and tools help find errors

Chapter 9 quiz

Question 1: What is the difference between syntax errors and semantic errors?

Question 2: Which type of code coverage measures whether both the true and false branches of conditional statements are tested? a) Line coverage b) Branch coverage
c) Function coverage d) Loop coverage

Question 3: What should you do after a failed std::cin operation? a) Only call std::cin.clear() b) Only call std::cin.ignore() c) Call both std::cin.clear() and std::cin.ignore() d) Restart the program

Question 4: When should you use assertions? a) To handle user input errors b) To check for file operation failures c) To verify programming assumptions and catch bugs d) To validate network connections

Question 5: What happens to assert() statements when NDEBUG is defined? a) They cause compilation errors b) They are disabled and removed from the code c) They print warnings instead of terminating d) They run normally

Question 6: Which of the following is an example of an off-by-one error?

a) for (int i = 0; i < 10; ++i)        // Print 0-9
b) for (int i = 1; i <= 10; ++i)       // Print 1-10  
c) for (int i = 0; i <= 10; ++i)       // Print 0-10
d) for (int i = 0; i < arr.size(); ++i) // Access all elements

Question 7: What is Test-Driven Development (TDD)? a) Testing code after it's completely written b) Writing tests before implementing the actual functions c) Using automated testing tools only d) Testing only the most important functions

Question 8: What's the main difference between assert() and static_assert? a) assert() is faster than static_assert b) static_assert checks conditions at compile time, assert() at runtime c) assert() provides better error messages d) static_assert is only for templates

Question 9: Which is the correct way to check if an integer division might cause truncation issues?

a) int result = a / b;                    // Direct division
b) double result = a / b;                 // Cast result to double  
c) double result = (double)a / b;         // Cast operand to double
d) int result = (a * 100) / b;            // Multiply first

Question 10: What does regression testing help ensure? a) All possible inputs are tested b) Code coverage reaches 100% c) New changes don't break existing functionality d) Tests run faster

Practice exercises

Now that you've completed Chapter 9, try these comprehensive exercises:

Exercise 1: Robust Calculator

Create a calculator program that:

• Validates all user input using proper std::cin error handling
• Uses assertions to check internal function preconditions
• Implements comprehensive test cases including edge cases
• Handles division by zero and other mathematical errors gracefully
• Provides clear error messages for all failure conditions

Exercise 2: Safe Array Class

Implement a dynamic array class that:

• Uses static_assert to validate template parameters
• Uses runtime assertions to check array bounds
• Implements comprehensive input validation for all methods
• Includes a full test suite with code coverage analysis
• Handles memory allocation errors appropriately

Exercise 3: File Processing System

Build a file processing system that:

• Validates file operations and handles missing files gracefully
• Uses assertions to verify internal state consistency
• Implements proper error logging for debugging
• Creates test cases that cover both successful and failed operations
• Provides user-friendly error messages for all failure modes

Exercise 4: Input Validation Library

Design a reusable input validation library with:

• Functions for safely reading integers, doubles, and strings
• Range validation with customizable limits
• Retry mechanisms with configurable attempt limits
• Comprehensive test coverage including boundary conditions
• Clear documentation and usage examples

What's next?

With Chapter 9 complete, you now have the skills to write robust, error-resistant C++ programs. You understand how to:

• Test your code systematically to catch bugs early
• Measure and improve test coverage
• Recognize and fix common semantic errors
• Detect and handle errors gracefully
• Validate user input safely
• Use assertions effectively for debugging

These error detection and handling skills are fundamental to professional C++ development. They'll serve you well as you tackle more complex programming challenges in future chapters.

In the next chapters, you'll build on these foundations to learn about more advanced C++ features like classes, templates, and the standard library. The error handling techniques you've mastered here will be essential as your programs become more sophisticated.

Quiz answers

1. Syntax errors prevent code from compiling (like missing semicolons), while semantic errors compile successfully but produce incorrect behavior due to logical mistakes.

2. b) Branch coverage - This measures whether both true and false paths of conditional statements are executed during testing.

3. c) Call both std::cin.clear() and std::cin.ignore() - You need to clear the error flags and skip the invalid input.

4. c) To verify programming assumptions and catch bugs - Assertions are debugging tools for internal consistency checks, not for handling expected runtime errors.

5. b) They are disabled and removed from the code - When NDEBUG is defined, assert() statements become no-ops.

6. c) for (int i = 0; i <= 10; ++i) - This loop runs 11 times (0-10) when you probably meant 10 times (0-9 or 1-10).

7. b) Writing tests before implementing the actual functions - TDD involves writing failing tests first, then implementing code to make them pass.

8. b) static_assert checks conditions at compile time, assert() at runtime - This is the fundamental difference between the two assertion types.

9. c) double result = (double)a / b; - Cast at least one operand to double before division to avoid integer truncation.

10. c) New changes don't break existing functionality - Regression testing ensures that bug fixes and new features don't introduce new problems.