Error Handling: Exceptions vs. Error Codes

1. The Classic Trade-Off: Clarity vs. Clutter

As we touched on before, the primary method for error handling in C is to use function return values. A function returns a special value (like 0, -1, or a specific enum) to indicate success or failure. The caller is then responsible for checking this value.

The main argument for exceptions is that this style of error checking clutters the primary logic of your program.

As the examples show, exceptions excel at separating the main algorithm from the error-handling logic. This separation leads to two key benefits:

1. Readability: The "happy path" is clean and easy to follow. Error handling is centralized in catch blocks, which are physically separate from the main flow.
2. Maintainability: When propagating an error up a deep call stack, you don't need to modify any of the intermediate functions. With return codes, every function in the chain must be modified to check and pass the error code along. This is tedious and error-prone.

Here's a summary of the classic arguments:

2. The Performance and Overhead Debate

The most common argument against exceptions is their perceived cost. This is where the comparison becomes much more nuanced.

The Cost of Throwing

When a throw occurs, the system does a lot of work:

1. Stack Unwinding: The program must walk back up the call stack, calling destructors for all local objects in each frame until a catch block is found.
2. Handler Matching: It often uses Run-Time Type Information (RTTI) to find a catch block that matches the type of the thrown exception.
3. Memory Allocation: The exception object itself is often allocated in a special, dynamically-managed memory area.

This process is significantly slower than a simple function return.

The "Zero-Overhead" Principle

C++ was designed with the zero-overhead principle: "what you don't use, you don't pay for." For exceptions, this means that if no exception is thrown, the performance cost should be minimal. Modern compilers are very good at this. In a try block, the code on the "happy path" runs at or very near native speed. The cost is only paid when an error actually occurs.

In contrast, a return-code approach pays a small cost—an if statement (a conditional branch)—on every single function call, regardless of whether an error occurred.

A Counter-intuitive View: Exceptions in Firmware

Given your interest in embedded systems, you might assume that exceptions are completely off-limits due to their overhead and non-determinism. While this is often the case, the full story is surprising.

The following talk investigates what happens when you challenge this dogma. It provides a data-driven comparison of binary size and performance.

The key insight is that while the upfront cost of enabling exceptions (in binary size) is higher, the marginal cost of adding another potential error site is near zero. For return codes, the upfront cost is zero, but every check adds a few bytes to the binary. In a large system with thousands of checks, this adds up.

3. Practical Guidance: Which to Choose?

There is no single answer. The choice depends on the nature of the error. A good heuristic is to distinguish between errors and failures.

• Use Exceptions for Exceptional Errors:

  • An error is a condition that prevents your function from fulfilling its fundamental contract (e.g., memory allocation failure, a file that must exist is corrupted, a network connection is unexpectedly lost).
  • These are situations where the caller likely cannot recover locally and the problem must be propagated up to a higher level of the application.
  • Constructor failures are the canonical example where exceptions are the only viable solution.

• Use Return Codes (or Modern Equivalents) for Expected Failures:

  • A failure is a predictable, alternative outcome of an operation (e.g., a user enters an invalid date, a search function doesn't find the item, a file open function fails because the file doesn't exist).
  • These are situations you expect to happen in the normal course of operation and can often be handled locally with a simple if statement.

For these expected failures, Modern C++ provides safer and more expressive alternatives to raw integer codes.

Modern Alternatives

1. std::optional (C++17)
   Use this when a function might or might not return a value. It elegantly handles the "found" vs. "not found" case without magic values like nullptr or -1.

   
   
   
   #include <optional>
   #include <iostream>
   
   std::optional<int> find_user_id(const std::string& username) {
       if (username == "admin") {
           return 1; // Found, returns an optional containing 1
       }
       return std::nullopt; // Not found, returns an empty optional
   }
   
   // Usage:
   if (auto id = find_user_id("guest"); id.has_value()) {
       std::cout << "User ID: " << id.value() << std::endl;
   } else {
       std::cout << "User not found." << std::endl;
   }
   

2. std::expected (C++23)
   This is the ideal modern replacement for return codes. It's a type that holds either an expected value (on success) or an unexpected error value (on failure).

   
   
   
   #include <expected>
   #include <string>
   #include <iostream>
   
   // A simple enum for our error types
   enum class ParseError { EmptyString, NotANumber };
   
   std::expected<int, ParseError> parse_integer(const std::string& s) {
       if (s.empty()) {
           return std::unexpected(ParseError::EmptyString);
       }
       try {
           return std::stoi(s);
       } catch (const std::invalid_argument&) {
           return std::unexpected(ParseError::NotANumber);
       }
   }
   
   // Usage:
   auto result = parse_integer("123");
   if (result) { // A bool-like check for success
       std::cout << "Parsed value: " << *result << std::endl;
   } else {
       switch (result.error()) {
           case ParseError::EmptyString:
               std::cerr << "Error: Input string was empty." << std::endl;
               break;
           case ParseError::NotANumber:
               std::cerr << "Error: Input is not a number." << std::endl;
               break;
       }
   }
   

   This gives you the locality and predictability of error codes but with type safety and clear intent.

Conclusion

You've now explored one of the most fundamental design trade-offs in C++. There's no universal "best" way to handle errors; context is everything.

Key Takeaways:

• Exceptions excel at separating the main logic from error handling. They provide robust, automatic propagation of serious, exceptional errors that cannot be handled locally. They are essential for reporting failures from constructors.
• Return Codes are simple and deterministic. They are best suited for handling predictable, local failures. However, they can clutter code and are easily forgotten.
• Performance is complex. Exceptions are expensive when thrown, but cheap when not. In large systems, the code-size overhead from thousands of return-code checks can exceed the overhead of the exception-handling tables, making exceptions a surprisingly efficient choice in some scenarios, even in resource-constrained environments.
• Modern C++ offers std::optional and std::expected as type-safe, expressive alternatives that capture the benefits of return codes without their main drawbacks.

As a developer, your job is to choose the right tool for the job. Is the condition you're handling a rare, system-level catastrophe or a predictable alternative path? Your answer will guide you to the correct error-handling strategy.

Next Up

In our next lesson, we will look at a feature that helps manage the complexity of types we've been dealing with. We'll learn to use the auto keyword for automatic type deduction, which can significantly improve code readability and make refactoring easier.