Error Handling in C++ or: Why You Should Use Eithers in Favor of Exceptions and Error-codes
TL;DR
Consider using an Either type to handle errors as they lift the error into the type-system and have the same performance characteristics as error-codes.
Either Implementations
Introduction
Programming language design is always a matter of trade-offs. In the case of C++, the designers optimized for two things: runtime efficiency and high-level abstraction. This gives the C++ programmer huge flexibility in many areas, one of which is error handling.
Exceptions & Try-Catch
Try-catch is traditionally seen as the most idomatic error-handling method in C++.
Exception Overhead
The try-catch language feature is not zero-cost and the exact price is determined by the compiler implementation. Implementers can choose between increased code-size and increased run-time overhead, both in the success branch and the failure branch.
In most C++ implementations, an interesting choice has been made: code in the try block runs as fast as any other code. However, dispatching to the catch block is orders of magnitude slower. This penalty grows linearly with the depth of the call-stack.
If exceptions make sense for your project will depend on the frequency at which exceptions will be thrown. If the error rate is above 1%, then the overhead will likely be greater than that of alternative approaches. (Source)
Exceptions are not supported by all platforms, and methods that throw cannot be easily understood by C.
Ergonomics
Exceptions are very easy to use and fairly easy to reason about. You can throw and catch exceptions at any point in your code, and the exception can even be an arbitrary type.
The biggest drawback is that handling exceptions is not enforced by the type-system. Unlike, Java, for example, where exceptions must be caught by the caller, catching a C++ exception is optional. This means spotting all the unhandled exceptions during a code review will be challenging, and requires deep knowledge of all of the functions called.
But what about noexcept and throw?
A common misconception is that annotating functions with noexcept or throw can help.
Unfortunately, noexcept and throw simply dictate that a call to std::terminate is made in the case where an unmentioned exception is thrown. This does not enforce any exception-handling at compile-time.
For example, these will compile and throw a run-time error!
Error-codes
Error-codes are ancient and used everywhere. For simplicity, let’s assume error-codes are just integers, but they could be implemented as type-safe enums or even complex objects. For this discussion it won’t really matter.
There are 3 common forms of error-code implementations.
1. Error-codes as Return Values
This pattern is found in many C APIs as it is easy to implement and has no performance overhead, besides the error-handling itself.
This pattern can be followed very dogmatically and it is easy to verify that all cases have been taken care of in a code-review. It is easy to write a C-friendly API using error-codes.
Unfortunately it has some drawbacks:
- Functional composition is hard. The return value is occupied by the error-code, so the result must be an out-variable, which makes the function impure.
- Out-parameters enforce a memory layout which is not optimizer friendly.
- Separating error-handling from the computation is difficult.
- Postponing error-handling requires the programmer to thread the error-code through the call-graph.
2. Error-code as out-parameter
Swapping the semantics of the out-parameter and return value has no significant advantages, except perhaps a slightly cleaner API. In the case where the error-code can be omitted, the API usage is simplified and functional compositionality is made easier.
This approach can be found in boost::asio (in fact boost::asio even makes it optional and falls back to throwing exceptions if no out-parameter is provided).
3. Error Singletons
Error singletons have completely different ergonomics. They are mostly found in low-level libraries that are implementing a system-global state-machine, such as a driver. One prominent example is OpenGL.
Using an error singleton looks like this:
In this paradigm, the status of the driver must be queried at run-time through a separate function. This appears to give you more freedom since you can query for errors when it is most appropriate, enabling you to better separate concerns. This allows the user to write code that resembles exception-based code, but without the cost of automatic stack unwinding.
Benefits for the API consumer:
- Error-handling can be reduced over time to a minimum
- Having fewer error-handling branches yields better performance
- No out-parameters are required, which increases functional compositionality
- Finalization can be performed manually when errors are found
But there are some big caveats:
- Singletons by design have shared state, thus writing thread-safe code is very hard
- No shortcutting of computation pipelines as no stack-unwinding occurs
- It is not clear which errors may be fired on which api-calls. The programmer must check the documentation.
- The severity of errors, and to recover from them, might be unclear
So what about Eithers?
An Either type is a container which takes a single value of one of two different types. A simple implementation might look like this:
To run computations on the wrapped value, an Either can provide some useful methods: leftMap, rightMap and join.
leftMaptransforms theleftValueto a new value if present, leaving a rightValue unchanged.rightMaptransforms therightValueto a new value if present, leaving a leftValue unchanged.jointakes a transformation for both sides of the Either where both transformations result in the same type. This allows an Either to be unified and unwrapped.
This is much easier to understand in code!
Now we are able to lift the exceptions into the type-system:
So what have we gained through this simple change?
We no longer need to pay for the overhead of exceptions and we have also encoded the exception-type into the function signature. This documents the error in the source-code and now the compiler will ensure that we handle the types properly.
This is a big deal, and it illustrates how powerful the C++ language is.
So what are the drawbacks?
First, you will need to add an Either type to you project. It is best not to reinvent the wheel here, and fortunately there are many open-source implementations available.
But what about performance? At first glance, it seems that every call to leftMap and rightMap will add a branch to the executable. In practice, the compiler is smart enough to optimize these away!
Take a look at this Compiler Explorer project; the branches of the various map calls dissappear.
For example, you might have noticed the following identity:
e.leftMap(f).leftMap(g) == e.leftmap([](auto x){ return g(f(x)); })And it turns out that the compiler does too. It combines both lambdas to inline the whole expression. After the optimization step, all abstractions are collapsed. Once complied, there is no significant difference between the error-code implementations and the either-based implementations.
Conclusion
Consider using an Either type to handle errors. They lift the error into the type-system, making them safer than exceptions whilst yielding the same performance characteristics as error-codes.
Resources
Either Implementations
Benchmarking Error-codes vs Exceptions vs Eithers
Return Values vs Out-Parameters
Some Code Samples
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
