Elegant Ways to Capture Exceptions from Java ThreadPool Tasks

When a task submitted to a Java thread pool throws an exception, the behavior differs between submit and execute: execute prints the stack trace, whereas submit silently swallows it, making debugging difficult.

The article starts with a minimal reproducible example:

public class ThreadPoolException {
    public static void main(String[] args) {
        ExecutorService executorService = Executors.newFixedThreadPool(1);
        // submit does not show the exception, other threads continue
        executorService.submit(new task());
        // execute prints the exception, other threads continue with new tasks
        executorService.execute(new task());
    }
}

class task implements Runnable {
    @Override
    public void run() {
        System.out.println("Entering task method!!!");
        int i = 1 / 0; // triggers ArithmeticException
    }
}

Running the code produces two screenshots: one where submit shows no error, and another where execute prints the exception stack trace.

To obtain the hidden exception from submit, the article shows that calling Future<?> submit = executorService.submit(new task()); followed by submit.get(); re‑throws the exception as an ExecutionException, which can be logged.

Solution 1: Inline try‑catch

Wrap the risky code inside a try‑catch block within the task:

public class ThreadPoolException {
    public static void main(String[] args) {
        ExecutorService executorService = Executors.newFixedThreadPool(1);
        executorService.submit(new task());
        executorService.execute(new task());
    }
}

class task implements Runnable {
    @Override
    public void run() {
        try {
            System.out.println("Entering task method!!!");
            int i = 1 / 0;
        } catch (Exception e) {
            System.out.println("Caught exception with try‑catch: " + e);
        }
    }
}

Both execute and submit now surface the exception via the printed message.

Solution 2: Custom ThreadFactory with UncaughtExceptionHandler

Define a thread factory that sets a default UncaughtExceptionHandler for every worker thread:

public class ThreadPoolException {
    public static void main(String[] args) throws InterruptedException {
        ThreadFactory factory = (Runnable r) -> {
            Thread t = new Thread(r);
            t.setDefaultUncaughtExceptionHandler((Thread thread, Throwable e) -> {
                System.out.println("ThreadFactory handler: " + e.getMessage());
            });
            return t;
        };
        ExecutorService executorService = new ThreadPoolExecutor(
                1, 1, 0, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<>(10), factory);
        executorService.submit(new task()); // no handler output
        Thread.sleep(1000);
        executorService.execute(new task()); // handler prints exception
    }
}

class task implements Runnable {
    @Override
    public void run() {
        System.out.println("Entering task method!!!");
        int i = 1 / 0;
    }
}

The screenshots confirm that the handler catches the exception from execute but not from submit, because submit wraps the task in a FutureTask that swallows the exception.

Why submit Swallows the Exception

The article inspects the JDK source. submit creates a FutureTask (a RunnableFuture) and passes it to execute. Inside FutureTask.run() the exception is caught and stored via setException(ex):

public void run() {
    if (state != NEW || !UNSAFE.compareAndSwapObject(this, runnerOffset, null, Thread.currentThread()))
        return;
    try {
        Callable<V> c = callable;
        if (c != null && state == NEW) {
            V result;
            boolean ran;
            try {
                result = c.call();
                ran = true;
            } catch (Throwable ex) {
                result = null;
                ran = false;
                setException(ex);
            }
            if (ran) set(result);
        }
        // ...
    } finally { /* omitted */ }
}

When Future.get() is invoked, the stored exception is retrieved from the internal outcome field and re‑thrown as an ExecutionException:

public V get() throws InterruptedException, ExecutionException {
    int s = state;
    if (s <= COMPLETING) s = awaitDone(false, 0L);
    return report(s);
}

private V report(int s) throws ExecutionException {
    Object x = outcome;
    if (s == NORMAL) return (V) x;
    if (s >= CANCELLED) throw new CancellationException();
    throw new ExecutionException((Throwable) x);
}

Solution 3: Overriding afterExecute

By subclassing ThreadPoolExecutor and overriding afterExecute(Runnable r, Throwable t), one can handle exceptions from execute directly. For submit, the method must detect a FutureTask and call future.get() to surface the stored exception:

ExecutorService executorService = new ThreadPoolExecutor(2, 3, 0, TimeUnit.MILLISECONDS,
        new LinkedBlockingQueue<>(10)) {
    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        if (t != null) {
            System.out.println("afterExecute caught execute exception: " + t.getMessage());
        }
        if (r instanceof FutureTask) {
            try {
                ((Future<?>) r).get();
            } catch (Exception e) {
                System.out.println("afterExecute caught submit exception: " + e);
            }
        }
    }
};
executorService.execute(new task());
executorService.submit(new task());

The resulting screenshots show that afterExecute now receives and logs exceptions from both submission styles.

In summary, execute naturally propagates uncaught exceptions, while submit hides them inside a FutureTask. Developers can either retrieve the exception with Future.get(), wrap task logic in a try‑catch, install a global UncaughtExceptionHandler via a custom thread factory, or override afterExecute to centralise error handling.