C++ Error Handling: Why Use Eithers in Favor of Exceptions and Error-Codes

C++ programs normally throw an exception when a C program would call exit() or abort().

So I would start by having one try block that surrounds your main() function with a catch-all block that prints some sort of error message before your program terminates. This is often all you need.

If a situation arises in which you can handle an exception without terminating your program, you can throw a try block in there too.

Exceptions automatically provide for you what you would write by hand in languages like C:

  // The C way

  int error_flag = EVERYTHING_IS_OK;

  int checked_div (int numerator, int denominator, int *quotient)
  {
    if (denominator == 0)
      return 1;

    *quotient = numerator / denominator;

    return 0;
  }

  int foo (int a, int b, int c)
  {
    int q;

    int err = checked_div (a, b, &q);
    if (err) {
      error_flag = FOO_DIV0;
    }

    return q+c;
  }

  // The exception way (notice that there's no try block)
  int checked_div (int numerator, int denominator)
  {
    if (denominator == 0)
      throw runtime_error ("Divide by zero!");

    return quotient;
  }

  int foo (int a, int b, int c)
  {
    return checked_div (a, b) + c;
  }

Returning error codes prevents functions from directly returning their results. The "eithers" strategy is an attempt to make this a little smoother, but it doesn't solve the problem that it makes your code weird. Global error flags have their own host of problems. If you fail to check for errors, havoc will ensue. Furthermore, multithreaded environments turn global error flags into a tangled web of deceit.

Nevertheless, these ad hoc strategies often suffice because the unusual nature of exceptional errors can prevent error handling code from clogging up your primary code path too badly. But even for simple situations, the compiler can do better than you can. Why add unnecessary complexity to your code?

You should write try/catch blocks only when you know how to cope with exceptional errors. Needless to say, they should be pretty rare. But lets say that when a particular invocation of foo() fails, we want to use the maximum integer value as our result. Here's how it looks:

  // The C way
  int bar (int a, int b, int c)
  {
    int result = foo (a, b, c);
    if (error_flag != EVERYTHING_IS_OK) {
      assert (error_flag == FOO_DIV0);
      result = numeric_limits<int>::max();
      error_flag = EVERYTHING_IS_OK;
    }

    return result;
  }

  // The exception way
  int bar (int a, int b, int c)
  {
    try {
      return foo (a, b, c);
    } catch (runtime_error)
      return numeric_limits<int>::max();
    }
  }

  int bar (int a, int b, int c)
  {
    return foo (a, b, c);
  }

  // This is only called when a runtime_error exception is thrown.
  int bar_catch (int a, int b, int c)
  {
    // return to the same place bar() returns to
    return numeric_limits<int>::max();
  }

This exception handling strategy is often referred to as the zero-cost exception mechanism. The latest versions of Clang, GCC, and 64-bit VC++ all implement some variation of it. For compilers that don't, there's a cost to adding try/catch blocks to your code. But it's still cheaper than the cost of your own error checking. Even if it tried, I don't know if a compiler could possibly implement exceptions in a way that's slower than a manual error handling approach.

There's a myth out there that exceptions add overhead or make the control flow of a program more difficult to reason about. Of course, this is the opposite of what they do. Even if you're working with C-like code that has no user-defined classes, switching to exceptions is a win. Exceptions enable some of the fundamental abstractions in C++. How else are you going to handle a memory allocation error in an implicitly-called copy constructor?

If you'd like to get a sense of just how perversely you need to contort the C++ language in order to deal with the absence of exceptions, look no further than Google's C++ style guide. Google doesn't use exceptions in their C++ code. This policy has ripple effects throughout their guidelines. Among other things, they forbid constructors from allocating resources.

https://google.github.io/styleguide/cppguide.html

Google's excuse for not using exceptions is that their existing exception-free code base is so large that it would take too much effort to convert it. But if they can interface C++ code with Java/Python/Go code, they should have no problem interfacing exception-free C++ with exception-full C++. I can't help but wonder if some of their engineers are confused about how exceptions work.

Anyway, if you don't work for Google, use C++ exceptions.

Wow. That turned into a rant (some of which was copy-pasted from something I wrote a while ago).

Which is why I actually like Java's Checked Exceptions, at least for public-API purposes.

It's really the exact same principle as having a contract for functions' return-values.

I wouldn't say that they are doing it wrong. They throw an exception because they don't want to make assumptions about how you would want to handle the error.

What would you prefer the std::stoi() function to do?

This programming style is very specific to the language. In another language, exception may be used more widely.

Ah, that's simply because C++ exceptions are unwind-only, non-restartable.

"Blub" exceptions.

> This is why exceptions are stupid - 80% of the time you want the context provided by the program counter.

Exactly.

Imagine if a CPU exception threw away that context. We couldn't implement virtual memory, which requires faulting instructions to be precisely restarted.

Such a design forces you to handle all errors near the place they occurred without the syntactic overhead. (Threading problems are overrated. Easy to dodge by providing a Context attribute which then works like IO monad in Haskell.)

It essentially works like exceptions without a forced stack unwind and return - which may or may not be good. Both are easy to convert and interoperate.

What runtime overhead, a function call? Pointer dereference? Even template magic on the error monad type won't save you from that one. The problem is shifted to the dereference. There you get either to handle an exception or error code, or explicitly check the state of the object.

Nested lambdas do work reasonably well.

But remember, were generally talking about error handling, not a callback that is supposed to run big transforms.

At worst the overhead is a function call anyway and inhibition of inlining in the error path. Generally nothing to worry about.

The pointer dereference and call overhead is not big and error handling code is supposed to be cold anyway.

Seriously, in some cases when you're going for example OOB, the only reasonable action is to dump core.

Trust me. This will improve your program, not make it worse.

Well, the bug here is that user input wasn't checked.

Then it's checked again inside the function

Checking twice is better than never checking at all (i.e. in the case argument validation didn't happen outside of the functiion)

Works out fantastic.

Including such connection failures or file open failures. They may have to be handled, but not at cost to the hot path.

You cannot typically just "eat" such an error with default behaviour and expect whatever relied on it to work properly.