What Happens When an Exception Goes Unhandled in a Multithreaded C++11 Program

What happens when an exception goes unhandled in a multithreaded C++11 program?

Nothing has really changed. The wording in n3290 is:

If no matching handler is found, the function std::terminate() is called

The behavior of terminate can be customized with set_terminate, but:

Required behavior: A terminate_handler shall terminate execution of the program without returning to the caller.

So the program exits in such a case, other threads cannot continue running.

Will main() catch exceptions thrown from threads?

Will main() catch exceptions thrown from threads?

No

When a thread throws an exception, it is not caught by main. Is this the standard behavior?

Yes, this is standard behaviour.

To catch an exception originating in thread X, you have to have the try-catch clause in thread X (for example, around everything in the thread function, similarly to what you already do in main).

For a related question, see How can I propagate exceptions between threads?

Exception propagation across threads?

Propagation is not automatic with thread. If a thread throws, and that exception is not caught, the program terminates no matter what.

future and shared_future will store an uncaught exception in the child thread. That exception is then automatically propagated when get is called.

std::thread supposedly leading to unusable stack trace

Presumably they have some custom exception handling mechanism which logs uncaught exceptions with a stack trace.

std::thread is defined to catch unhandled exceptions and call std::terminate:

if it terminates by throwing an exception, std::terminate is called

https://en.cppreference.com/w/cpp/thread/thread

.NET multi-thread and exceptions

Unhandled exceptions terminate the program since .NET 2.0. Thinking that the main thread gets "interrupted" isn't the right mind-set, the entire program gets aborted and all the threads die. It is the "rude" version of Thread.Abort() and cannot be stopped.

There's one last gasp through the AppDomain.UnhandledException event. It fires to gives you a chance to log the value of e.UnhandledException.ToString() so you'll have a shot at diagnosing the crash. Often overlooked btw but essential to deal with crashes when your program goes out in the wild and users and their machines treat your program in often very surprising ways you didn't envision.

It is actually possible to not make the program crash with an attribute in the .config file that overrides the default CLR policy. But that way lies madness, threads that terminate without finishing their job just cause programs to misbehave in completely undiagnosable ways. Tried in .NET 1.x and rejected as a Bad Idea.

java thread exceptions

We are talking about unchecked exceptions thrown from Thread.run method.
By default, you will get sth like this in system error:

Exception in thread "Thread-0" java.lang.RuntimeException
    at Main$1.run(Main.java:11)
    at java.lang.Thread.run(Thread.java:619)

This is the result of printStackTrace for unhandled exceptions. To handle it, you can add your own UncaughtExceptionHandler:

   Thread t = new Thread(new Runnable(){
        public void run() {
            throw new RuntimeException();
        }       
    });
   t.setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {

        public void uncaughtException(Thread t, Throwable e) {
            System.out.println("exception " + e + " from thread " + t);
        }
    });
    t.start();

To set handler for all threads use a static method Thread.setDefaultUncaughtExceptionHandler.

---

Related Topics