Attempt to report uncaught exceptions in the test module (#3449)

When when a `Job` doesn't have a parent, failures in it can not
be reported via structured concurrency. Instead, the mechanism of
unhandled exceptions is used. If there is a
`CoroutineExceptionHandler` in the coroutine context or registered
as a `ServiceLoader` service, this gets notified, and otherwise,
something platform-specific happens: on Native, the program
crashes, and on the JVM, by default, the exception is just logged,
though this is configurable via
`Thread.setUncaughtExceptionHandler`.

With tests on the JVM, this is an issue: we want exceptions not
simply *logged*, we want them to fail the test, and this extends
beyond just coroutines. However, JUnit does not override the
uncaught exception handler, and uncaught exceptions do just get
logged:
<https://stackoverflow.com/questions/36648317/how-to-capture-all-uncaucht-exceptions-on-junit-tests>

This is a problem with a widely-used `viewModelScope` on Android.
This is a scope without a parent, and so the exceptions in it are
uncaught. On Android, such uncaught exceptions crash the app by
default, but in tests, they just get logged. Clearly, without
overriding the behavior of uncaught exceptions, the tests are
lacking. This can be solved on the test writers' side via
`setUncaughtExceptionHandler`, but one has to remember to do that.

In this commit, we attempt to solve this issue for the overwhelming
majority of users. To that end, when the test framework is used,
we collect the uncaught exceptions and report them at the end of a
test. This approach is marginally less robust than
`setUncaughtExceptionHandler`: if an exception happened after the
last test using `kotlinx-coroutines-test`, it won't get reported,
for example.

`CoroutineExceptionHandler` is designed in such a way that, when it
is used in a coroutine context, its presence means that the
exceptions are safe in its care and will not be propagated further,
but when used as a service, it has no such property. We, however,
know that our `CoroutineExceptionHandler` reports the exceptions
properly and they don't need to be further logged, and so we had to
extend the behavior of mechanism for uncaught exception handling so
that the handler throws a new kind of exception if the
exception was processed successfully.

Also, because there's no `ServiceLoader` mechanism on JS or Native,
we had to refactor the whole uncaught exception handling mechanism
a bit in the same vein as we had to adapt the `Main` dispatcher
to `Dispatchers.setMain`: by introducing internal setter APIs that
services have to call manually to register in.

Fixes #1205
as thoroughly as we can, given the circumstances.

1 files changed, 2 insertions, 1 deletions

diff --git a/integration-testing/src/jvmCoreTest/kotlin/ListAllCoroutineThrowableSubclassesTest.kt b/integration-testing/src/jvmCoreTest/kotlin/ListAllCoroutineThrowableSubclassesTest.kt
index 21fe496b..7253658e 100644
--- a/integration-testing/src/jvmCoreTest/kotlin/ListAllCoroutineThrowableSubclassesTest.kt
+++ b/integration-testing/src/jvmCoreTest/kotlin/ListAllCoroutineThrowableSubclassesTest.kt
@@ -27,7 +27,8 @@ class ListAllCoroutineThrowableSubclassesTest {
         "kotlinx.coroutines.JobCancellationException",
         "kotlinx.coroutines.internal.UndeliveredElementException",
         "kotlinx.coroutines.CompletionHandlerException",
-        "kotlinx.coroutines.DiagnosticCoroutineContextException",
+        "kotlinx.coroutines.internal.DiagnosticCoroutineContextException",
+        "kotlinx.coroutines.internal.ExceptionSuccessfullyProcessed",
         "kotlinx.coroutines.CoroutinesInternalError",
         "kotlinx.coroutines.channels.ClosedSendChannelException",
         "kotlinx.coroutines.channels.ClosedReceiveChannelException",