The Problem with Exceptions

Exceptions are a powerful tool for error handling in C++, but they come with a few drawbacks. They can be slow, especially when thrown across module boundaries. They can also lead to resource leaks if not handled correctly. And they can be misused, leading to code that’s hard to read and maintain.

C++ has come a long way. We started with the basics in C++98/03, then got a massive upgrade with C++11/14/17 (lambdas, smart pointers – you know the drill!). C++20 was huge with concepts and ranges, and now C++23, officially released in 2024, gives us std::expected, along with some other goodies.

The International Organization for Standardization (ISO) keeps C++ evolving, with a new standard roughly every three years. Right now, in February 2025, C++23 is the current standard. We’re already looking ahead to C++26, which might bring some cool (but still experimental) stuff like reflection. But I digress – let’s get back to std::expected.

The Way Handling Old Errors

We’ve all been there. Here’s a quick recap of the classic ways to handle errors, and why they sometimes fall short.

try {
    // Do something that might throw an exception
} catch (const std::exception& e) {
    // Handle the exception
}

int doSomething() {
    // Do something that might fail
    return -1; // Failure
}

struct Result {
    bool success;
    int value;
    std::string error;
};

Enter The Hero We Deserved

std::expected is a template class (you’ll find it in the expected header) that elegantly solves these problems. Think of it as a container that holds either a successful result (of type T) or an error (of type E). It’s always in one of those two states – it can never be empty. When you see a function signature like std::expected<int, std::string>, you know immediately that it might fail, and what kind of error it might return. No more guessing! There is no no exception-handling overhead and it’s part of the C++ standard library, so everyone can use it the same way.

But how to use it? Well. Here is a little example.

#include <expected>
#include <string>
 
std::expected<int, std::string> parseToInt(const std::string& s) {
    try {
        size_t idx;
        int num = std::stoi(s, &idx);
        if (idx != s.length()) {
            return std::unexpected("Invalid characters after number");
        }
        return num;
    } catch (const std::invalid_argument& e) {
        return std::unexpected("Invalid input");
    } catch (const std::out_of_range& e) {
        return std::unexpected("Number out of range");
    }
}

In this example, the function parseToInt tries to convert a string to an integer. If it succeeds, it returns the integer. If it fails, it returns an error message. The caller can then check if the result is valid and handle the error accordingly.

You need it more generic? No problem. You can use std::expected with any type, not just int and std::string. You can even nest std::expected inside another std::expected to handle multiple errors. The possibilities are endless! Here is a more generic example:

template <typename T>
T parseInt(const std::string& str) {
    try {
        size_t pos;
        long long value = std::stoll(str, &pos);
 
        // Ensure full parsing and valid range
        if (pos != str.length()) {
            throw std::invalid_argument("Invalid integer format");
        }
        if (value < std::numeric_limits<T>::min() || value > std::numeric_limits<T>::max()) {
            throw std::out_of_range("Integer out of range");
        }
        return static_cast<T>(value);
    } catch (const std::exception& e) {
        throw std::invalid_argument("Failed to parse integer: " + str);
    }
}

Both examples demonstrates how std::expected communicates both success and failure clearly, reducing the risk of overlooking error checks. I think that it is a powerful tool that makes code more readable and maintainable.

The Monadic Operations

std::expected supports monadic operations, which means you can chain operations together without having to check for errors at each step. The transform for example applies a function to the expected value if present, returning a new std::expected. With or_elseyou can provide a fallback value if the operation fails. And with and_then you can chain operations together, passing the result of one operation to the next. This is a powerful way to handle errors with functional programming techniques. Modern C++ is getting more and more functional, and std::expected is a great example of that.

So how to chain operations? Here is an example:

auto finalResult = parseToInt("123").and_then([](int num) {
    // Another function returning std::expected<int, std::string>
    return divideBy(num, 2);
});
if (finalResult.has_value()) {
    std::cout << "Result: " << finalResult.value() << std::endl;
} else {
    std::cout << "Error: " << finalResult.error() << std::endl;
}

Did you see how this reduces nested if statements? It is making code cleaner and more maintainable, especially for sequences of operations that can fail.

Community Trends and Adoption

I’ve seen a lot of excitement in the C++ community around std::expected. And we should talk about adoption of modern standards within the community. Surveys, such as the JetBrains’ Developer Ecosystem 2023 report (InfoWorld state of C++ developer ecosystem 2023), indicate C++20 is now the base dialect, with C++23 gaining traction, driven by conference talks and tool support. GitHub trending repositories, like Hyprland and Meshtastic, show active C++ development, often using modern standards, reinforcing the relevance std::expected.

Please remark that compilers like GCC 12 and MSVC 19.33 (Visual Studio 2022 17.3) support std::expected, making it accessible for developers. Community discussions, such as on Stack Overflow, highlight its usability.

Comparative Analysis with Future Standards

Looking ahead, C++26 is expected to bring more functional programming features, like pattern matching and reflection. These features could complement std::expected, enhancing error handling and data processing. The C++ community is already discussing these features, with proposals like P1371 (Pattern Matching) and P2213 (Reflection) gaining traction. However, C++26, still in development, may propose the features like reflection and contracts, but these are experimental and not yet standardized. std::expected, being part of C++23, is a stable(!), current feature, making it more relevant for immediate adoption compared to future proposals.

std::expected was selected as the focus due to its recency (introduced in C++23, published 2024), relevance for modern error handling, and community interest, as seen in blogs like C++ Stories using std::expected in C++23 and Modern C++ Blog on std::expected for error handling. It addresses current developer needs for explicit, efficient error handling, supported by recent compiler versions.

My Take on std::expected

I am excited about std::expectedand its potential to improve the language.

std::expected in C++23 is a significant advancement for error handling, offering a standardized, efficient, and clear alternative to exceptions and error codes. Its support for monadic operations enhances code. For developers writing new or updating existing C++ code, adopting std::expected can improve robustness.

I hope this article has given you a good overview of std::expected and its benefits. I can only encourage you to explore it further and see how it can improve your C++ code. Happy coding, guys!

References

1. cppreference: std::expected - Comprehensive reference for std::expected with usage examples and technical details. [Accessed: 22.02.2025]
2. Using std::expected from C++23 - An article on C++ Stories about std::expected in C++23. [Accessed: 22.02.2025]
3. C++23: A New Way of Error Handling with std::expected - A blog post on Modern C++ Blog discussing std::expected for error handling. [Accessed: 22.02.2025]
4. InfoWorld: State of C++ developer ecosystem - Insights on C++ developer trends and standards adoption. [Accessed: 22.02.2025]
5. StackOverflow Community Discussion about std::exception - Community discussion on Stack Overflow about std::expected. [Accessed: 22.02.2025]