Properly handle exceptions in threads created by MongoClient

[abalanonline]

Hello dear mongo-java-driver maintainers,
Please allow me to contribute this bugfix. The problem with Throwable in this line is that
it catches errors (OutOfMemoryError in particular) and doesn't let JVM crash leaving it
in zombie state - unable to recover, unable to exit.

JAVA-5913

[rozza]

Thanks @abalanonline for the PR.

I've added JAVA-5913 to track this. It'll be triaged in due course.

Ross

[stIncMale]

Hi @abalanonline, thank you for the PR.

1. The place your identified is not the only place where we were incorrectly catching and swallowing Throwable.
2. Also, there are a number of threads created by MongoClient that may be silently terminated due to a throwable. I updated those places such that we log a message and rethrow, allowing applications to handle such throwables via the default UncaughtExceptionHandler.

@abalanonline, @rozza please take a look, but hide whitespaces when reviewing to see the meaningful changes.

[abalanonline]

Well, catching the error, logging and rethrowing it will work. I can give verbal approval.
But since you asked for my opinion, I would kindly suggest removing all Error catching from the code and letting the JVM handle them. Alternatively, the user of the client library can handle such errors themselves if they are confident enough.

[stIncMale]

suggest removing all Error catching from the code and letting the JVM handle them. Alternatively, the user of the client library can handle such errors themselves if they are confident enough.

The only behavioral difference between my approach and the approach you propose is logging. The issue with not logging is that when an internal MongoClient thread terminates due to an exception, the application that does not have the default UncaughtExceptionHandler configured, will have no easy way of knowing that the problem occurred. And the majority of application developers probably don't know about the internal MongoClient threads (why would they?), thus not necessarily suspecting that it may be useful to configure the default UncaughtExceptionHandler. This is why I deem log messages about unexpected termination of internal threads useful.

[abalanonline]

I agree. Logging the error seems to be the best option.

[Copilot]

Pull Request Overview

This PR addresses a critical bug where catching Throwable in background threads could prevent the JVM from properly handling fatal errors like OutOfMemoryError, leaving the application in a zombie state. The fix ensures fatal errors can propagate to terminate the JVM while still handling recoverable exceptions appropriately.

• Replaces broad Throwable catches with more specific Exception catches in thread monitoring loops
• Adds proper exception handling with logging and re-throwing for background worker threads
• Improves error messages to provide more context about which component stopped working

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
MongoClient.java	Adds exception handling to cursor cleaning thread with logging and re-throwing
TlsChannelStreamFactoryFactory.java	Adds exception handling to TLS selector loop with logging and re-throwing
PowerOfTwoBufferPool.java	Adds exception handling to buffer pool pruning thread with logging and re-throwing
LoadBalancedCluster.java	Adds exception handling to wait queue handler thread with logging and re-throwing
DefaultServerMonitor.java	Narrows exception handling from Throwable to Exception in monitoring loops, adds exception handling to main monitor thread
DefaultDnsSrvRecordMonitor.java	Adds exception handling to DNS SRV record monitoring thread with logging and re-throwing
DefaultConnectionPool.java	Updates error message to include object context
BaseCluster.java	Adds exception handling to wait queue handler thread with logging and re-throwing
AsynchronousClusterEventListener.java	Adds exception handling to event publishing thread with logging and re-throwing