Handling Exceptions in Asynchronous Tasks

The Problem: Exceptions Don't Cross Thread Boundaries

When you call a function directly, an exception propagates up the call stack until it's caught. With threads, this chain is broken. Each thread has its own independent call stack. An exception thrown in a worker thread will unwind that thread's stack, and if it's not caught, it will call std::terminate, crashing your entire application.

Let's see a clear demonstration of this problem and the desired solution.

As the article shows, the goal is to make our ThreadPool::submit behave like std::async. The std::future object must become a conduit not just for the return value, but for exceptions as well.

The Mechanism: promise, exception_ptr, and packaged_task

The standard library provides the tools to build this conduit. The key components are:

1. std::promise::set_exception(): We've used promise::set_value() to fulfill a promise with a result. The counterpart, set_exception(), allows us to fulfill it with an error.
2. std::exception_ptr: You can't pass raw exception objects between threads; you'd run into object slicing and lifetime issues. The C++ standard provides a special, type-erased, sharable pointer called std::exception_ptr. You capture the current exception with std::current_exception() and store the resulting exception_ptr in the promise.
3. std::rethrow_exception(): On the client side, when future::get() is called, the future's internal logic can check if it holds an exception_ptr. If so, it calls std::rethrow_exception(), which re-throws the original exception, preserving its type and data.

Let's see how these pieces fit together. We could modify the task lambda in our submit function to include a try...catch block:

// Inside ThreadPool::submit...
auto task_wrapper = [/* captured function and args */, promise]() {
    try {
        // ... invoke the user's function ...
        // ... set value on promise ...
    } catch (...) {
        // If an exception occurs, capture it and store it in the promise.
        promise->set_exception(std::current_exception());
    }
};
tasks.push(std::move(task_wrapper));

This works, but there's an even cleaner way. The standard library provides an abstraction that encapsulates this exact pattern: std::packaged_task.

A std::packaged_task wraps a callable target. When you invoke the packaged_task object, it calls the target function and stores the return value or any thrown exception in a shared state that can be accessed via a std::future.

This is exactly what we need! It simplifies our code and delegates the complex exception-handling logic to the standard library.

Refactoring with std::packaged_task

The following video provides an excellent walkthrough of refactoring from a manual promise/future implementation to one using standard library components, culminating in std::packaged_task.

Inspired by that refactoring, we can now update our ThreadPool::submit method. Instead of creating a promise and a complex lambda manually, we'll wrap the user's function in a std::packaged_task.

The task we push to our queue will no longer be the user's work directly. It will be a simple lambda that, when executed, calls the packaged_task.

// In ThreadPool.h

#include <future>
#include <functional>
#include <vector>
// ... other includes

class ThreadPool {
    // ...
private:
    // Our task queue now holds type-erased functions. std::function is a common choice.
    ThreadSafeQueue<std::function<void()>> tasks; 
    // ...
};

// In ThreadPool.h or ThreadPool.cpp

template<typename Func, typename... Args>
auto ThreadPool::submit(Func&& func, Args&&... args) -> std::future<std::invoke_result_t<Func, Args...>> {
    using ReturnType = std::invoke_result_t<Func, Args...>;

    // 1. Create a packaged_task that wraps the user's function and its arguments.
    // We use std::bind to bundle the function and its arguments into a single callable.
    // A shared_ptr is used because the task will be moved into the lambda below, 
    // so we need shared ownership.
    auto task_ptr = std::make_shared<std::packaged_task<ReturnType()>>(
        std::bind(std::forward<Func>(func), std::forward<Args>(args)...)
    );

    // 2. Get the future from the packaged_task. This is what we'll return to the client.
    std::future<ReturnType> future = task_ptr->get_future();

    // 3. Push a simple, type-erased lambda into the queue.
    // This lambda, when executed by a worker, will invoke the packaged_task.
    tasks.push([task_ptr]() {
        (*task_ptr)();
    });

    // An optional step: notify one waiting worker thread if you have a condition variable.
    // tasks_cv.notify_one(); 
    
    return future;
}

Our worker loop now becomes incredibly simple. It doesn't need to know anything about promises or exceptions. It just executes the std::function<void()> it pops from the queue.

// Inside the worker loop
void worker_loop(std::stop_token stoken) {
    while (!stoken.stop_requested()) {
        std::function<void()> task;
        if (tasks.wait_and_pop(task, stoken)) {
            // Simply execute the task. The packaged_task inside handles everything.
            task();
        }
    }
}

With this change, our thread pool now correctly propagates exceptions.

Under the Hood: How exception_ptr Works

Since you're interested in how things work from first principles, let's dive deeper. What is an exception_ptr? How does std::current_exception() capture an exception?

This machinery is built on top of the C++ runtime's low-level exception handling ABI (Application Binary Interface). On Linux, this is typically the Itanium C++ ABI.

Here's the key takeaway from the article:

1. When you throw an object, the compiler generates a call to __cxa_allocate_exception. This function allocates memory on the heap for the exception object and a special header (__cxa_exception).
2. This header contains crucial metadata: a pointer to the object's std::type_info, a destructor, reference counters, and more.
3. The compiler then constructs the exception object in this allocated memory.
4. Finally, __cxa_throw is called, passing it a pointer to this allocated block. This pointer begins the stack unwinding process.

An std::exception_ptr is essentially a smart, reference-counted pointer to this runtime-managed exception object on the heap.

• std::current_exception() grabs a handle and increments the reference count on the __cxa_exception block. This ensures the exception object outlives the catch block it was captured in.
• promise.set_exception(ptr) stores this smart pointer.
• future.get() finds this stored pointer and calls std::rethrow_exception(ptr), which uses the metadata in the __cxa_exception header (like the type_info) to re-create and re-throw the original exception with its correct type.

This mechanism allows an exception to be "paused", passed across a thread boundary, and "resumed" in a different context, which is exactly what our thread pool requires.

Updating Unit Tests

The final step is to verify our implementation. We need to add a test case to our Google Test suite that proves exceptions are propagated correctly.

// In your thread pool test file...
#include <stdexcept>

TEST(ThreadPoolException, PropagatesException) {
    ThreadPool pool(2); // Create a pool with 2 threads

    // 1. Define a function that is guaranteed to throw
    auto task_that_throws = []() {
        throw std::runtime_error("This is a test exception");
    };

    // 2. Submit the task and get its future
    std::future<void> future = pool.submit(task_that_throws);

    // 3. Use ASSERT_THROW to verify that future.get() re-throws the correct exception type
    try {
        future.get();
        FAIL() << "Expected std::runtime_error, but no exception was thrown.";
    } catch (const std::runtime_error& e) {
        // 4. (Optional but good) Check the exception message
        ASSERT_STREQ("This is a test exception", e.what());
    } catch (...) {
        FAIL() << "Expected std::runtime_error, but a different exception was thrown.";
    }
}

This test provides concrete evidence that our feature is working as intended.

Conclusion

Congratulations! You have now implemented one of the most critical features for a production-ready tasking system. By ensuring exceptions are propagated correctly, you've made the thread pool safer, more predictable, and easier to debug for its users.

Key Takeaways:

• Exceptions thrown in a worker thread must be caught and propagated back to the client thread via the std::future.
• The standard mechanism involves try...catch in the task wrapper, std::current_exception() to capture the error into an std::exception_ptr, and promise::set_exception() to store it.
• std::packaged_task is a powerful abstraction that automates this entire process, simplifying the code and reducing the chance of errors.
• At a low level, std::exception_ptr works by managing a reference-counted handle to the heap-allocated exception object created by the C++ runtime's ABI (e.g., __cxa_allocate_exception).

Next Lesson Preview:

Our thread pool is now highly functional, with dynamic sizing and robust error handling. But is it correct under heavy load? Concurrency bugs are notoriously difficult to find. In the next lesson, we will focus on implementing stress tests to identify race conditions, deadlocks, and performance bottlenecks, and we'll introduce tools to help us analyze the pool's behavior under pressure.