How to prevent Sentry from suppressing stderr exceptions

Today I ran into a mildly annoying issue with Sentry for JVM and found it surprisingly hard to google a proper solution.

Let’s say you have a backend Java/Kotlin service which uses Sentry SDK (mine had both Sentry SDK and SentryAppender for Logback, but it doesn’t seem to make any difference).

If the service crashes on startup, the error is reported to Sentry as expected but is not printed to stderr anymore. Normally this isn’t an issue, but it can become annoying when you’re just launching things from your IDE. I imagine no one wants to go to the web UI just to learn that your local Redis port was set to a wrong number.

The reason it happens is that Sentry registers its own handler via Thread#setDefaultUncaughtExceptionHandler (controlled by the configuration option isEnableUncaughtExceptionHandler which is true by default). When I was researching the stacktrace issue, some sources described how to write a custom wrapper around Sentry’s handler (which already looked like overkill); others suggested turning off isEnableUncaughtExceptionHandler altogether.

Turns out there’s a simpler way — just set the isPrintUncaughtStackTrace option to true and that’s it.

Here’s a Kotlin example:

Sentry.init { options ->
    options.dsn = ...
    ...        
    options.isPrintUncaughtStackTrace = true
}

Console output example with isPrintUncaughtStackTrace = false (default):

20:42:49.738 [main] INFO  com.example.Application -- Initializing Redis connection for whatever reason

Process finished with exit code 1

Console output example with isPrintUncaughtStackTrace = true:

20:42:49.738 [main] INFO  com.example.Application -- Initializing Redis connection for whatever reason
Exception in thread "main" redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
	...
Caused by: redis.clients.jedis.exceptions.JedisConnectionException: Failed connecting to localhost:111
	...
Caused by: java.net.ConnectException: Connection refused
	...

Process finished with exit code 1