Idiomatic catching of unchecked exceptions in ExecutorService.submit
Exception handling in Java has certain best practices. But not all situations are covered equally.

In this case, what you have, is a combination of logging, handling, and shutdown handling.

In this case, your handling appears to be sane. The centralization of this logging/shutdown is convenient because it essentially extracts the same functionality from multiple places in to a single place.

There are two issues that I can see:


Logging in Java often is tied to the class that the log message is called from. For example, the Logger is created with a name of the class as a constructor/key.

This means that the logging of the exception may/will be logged with the name of the ErrorHandler class rather than the class that threw the exception.

Depending on your circumstances, this may be a problem.
Logic flow in situations like this are often complicated by the return types of the class. For example, your code may look like:

public int myMethod() {
    try {
        // .... do something ....
        return 1;
    } catch (LWJGLException ex) {
        exceptionHandler.onException(ex);
    }
}


but, that code will not compile because you need to return an int value after handling the exception.

You know that there will never be an exit from the onException, because it shuts down. The compiler does not know that, so the compiler makes the wrong assessment of the exit path of the method.

I recommend you change the signature of the onException class, to have a return type of RuntimeException. With that, you can have:

   } catch (LWJGLException ex) {
       throw exceptionHandler.onException(ex);
   }


That will keep the compiler happy too.