You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently exceptions thrown by CoroutineExceptionHandler are retrown from the handleCoroutineException(), possibly wrapped into a RuntimeException:
publicactualfunhandleCoroutineException(context:CoroutineContext, exception:Throwable) {
try {
/* invoke CoroutineExceptionHandler.handleException() and currentThread.uncaughtExceptionHandler.uncaughtException() */
} catch (handlerException:Throwable) {
// simply rethrow if handler threw the original exceptionif (handlerException === exception) throw exception
// handler itself crashed for some other reason -- that is bad -- keep boththrowRuntimeException("Exception while trying to handle coroutine exception", exception).apply {
addSuppressed(handlerException)
}
}
}
It is unclear now what consequences this behavior can lead to, but the comment inside the catch { ... } clause, telling that -- that is bad -- is probably right.
It feels that handleCoroutineException() must guarantee not to throw, or at least make sure the exception is delivered to a proper piece of code that is expecting it.
Some background:
val exceptionHandler = context[CoroutineExceptionHandler] ?:CoroutineExceptionHandler { coroutineContext, throwable ->LOG.error("Unhandled exception from $coroutineContext", throwable)
}
This seemingly harmless piece of logic can actually throw an AssertionError in IDEA when running in unit testing mode. What is the right way of dealing with it?
The text was updated successfully, but these errors were encountered:
I don't have a good answer. Coroutine exception handler is the last resort. If it throws exception then what else we can do with it? The only suggestion I can make is that we can have a separate try-catch for a user-defined exception handler (like in your case) and if that crashed, then we can use a default exception handler as a fall-back.
Currently exceptions thrown by
CoroutineExceptionHandler
are retrown from thehandleCoroutineException()
, possibly wrapped into aRuntimeException
:It is unclear now what consequences this behavior can lead to, but the comment inside the
catch { ... }
clause, telling that-- that is bad --
is probably right.It feels that
handleCoroutineException()
must guarantee not to throw, or at least make sure the exception is delivered to a proper piece of code that is expecting it.Some background:
This seemingly harmless piece of logic can actually throw an
AssertionError
in IDEA when running in unit testing mode. What is the right way of dealing with it?The text was updated successfully, but these errors were encountered: