Question

I have a class that distributes work given by the user to several threads. Something like (simplified):

class MT {
public:

    MT();

    void work1(/*args*/);
    void work2(/*args*/);
    void work3(/*args*/);

    //waits until all threads complete, returns whether the work has been completed
    //successfully, throws any exceptions that have been raised in the threads.
    bool is_ok(); 

    ~MT();

private:
    // thread pool
}

The user uses the class as follows:

void foo()
{
    MT mt;
    mt.work1(/*userdata*/);
    mt.work2(/*userdata*/);
    mt.work1(/*userdata*/);
    status = mt.is_ok();
    if (status) {
        mt.work3(/*userdata*/);
        //...
    }
    //...
}

The class is never part of some object, always stored on the stack.

The Problem

I want to somehow emit any exceptions that have been raised while doing work in other threads. Unfortunately, I know whether a thread has successfully completed only after joining it. Thus, I must choose between the following two alternatives:

• Join the threads in the destructor of MT and throw exceptions that arose while doing work, if any. If more than one exception has been thrown, pick the one that came from the earliest task. If the destructor is called doing stack unwinding (we can check this using std::uncaught_exception, swallow any exceptions to prevent terminate().

• Instruct the user to always call is_ok before the destructor.

I think the first option is cleaner, since the user is not required to call anything. However, throwing from destructor is usually very strongly discouraged. The presented arguments are:

• Throwing from destructors is dangerous, because this might happed during stack unwinding and lead to terminate().
• Even if the above is addressed, throwing or not throwing depending on whether stack is being unwound is a substantial change of behavior and should be discouraged.
• Exceptions signify that a postcondition have not been met. The postcondition of a destructor is resource cleanup, this must be possible in any circumstances.

Somehow I am inclined to think that the above arguments don’t apply here:

• I handle the stack unwinding problem properly
• Due to the usage pattern, any exceptions that exit from foo means that work has been failed. Throwing or not throwing in the destructor is not a substantial change of behavior.
• The postconditions of the destructor are not only resource cleanup, but also that the work has been completed successfully. Thus an exception should be appropriate.

Questions

• Do you think throwing from destructor is appropriate in this case?

Answer 1

No, don’t throw from the destructor. Call is_ok, catch and ignore. Same as close() for streams.

The user can call is_ok if they want to be sure that the work has been completed, and it will throw an exception on failure.

In practice this is rarely inconvenient. It will be if the user writes a function with multiple return points, but (unfortunately) that’s a problem they just have to deal with because C++ doesn’t provide a means for you to do it for them. If you think this is anti-social, well, look at what happens if you destroy a std::thread in C++11 without first either joining it or detaching it. You’re beating that 🙂

So, user calls is_ok on all non-error exit paths. User doesn’t bother calling it when there’s already an exception, because they can’t deal with another one anyway. Again, this is the same as close() for streams: if you want to see errors from writing your buffered stream then you just have to close or flush explicitly.

Even if the above is addressed, throwing or not throwing depending on
whether stack is being unwound is a substantial change of behavior and
should be discouraged.

It’s also not possible to do correctly, at least in C++03. I don’t know whether C++11 changes anything in this respect, but std::uncaught_exception does not tell you what you need to know, as Herb Sutter explains.

From your link to cppreference.com:

Any exception thrown while std::uncaught_exception() == true calls std::terminate.

I’m pretty sure this is false. terminate is called if an exception escapes a destructor that is called as part of stack unwinding, but it isn’t called just because a destructor throws and catches an exception during unwinding.

If the caller thinks they can do something useful with an exception thrown in a destructor, then they can write a helper class that calls is_ok in its destructor, and put that over your object. If you think there’s something useful that your class can do with the same exception then you can do something other than merely ignore it in your destructor, but you still shouldn’t allow it to leave the destructor.