Terminate the process in case of an unhandled exception #2804
Conversation
* Provides newSingleThreadedContext. * Provides Dispatchers.Main on iOS, Dispatchers.Default everywhere. * Coroutine references (Job), all kinds of channels and StateFlow are shareable across workers. * Each individual coroutine is confined to a single worker. * Update Dispatchers docs to account for native-mt changes. * Multithreaded support in select expression. * Fix ObjC autorelease object leaks with native-mt dispatchers (#2477) Additional fixes: * Fixed broadcast builder with different thread * Fixed adding a child to a frozen parent job Fixes #462 Fixes #470 Fixes #765 Fixes #1645 Fixes #1751 Fixes #1828 Fixes #1831 Fixes #1764 Fixes #2064 Fixes #2025 Fixes #2226 Fixes #2138 Fixes #2263 Fixes #2322 Fixes #2283 Fixes #2688
kotlinx-coroutines-core/native/src/CoroutineExceptionHandlerImpl.kt
Outdated
Show resolved
Hide resolved
| throw exception | ||
| // Use unhandled exception hook if it is set, otherwise print the stacktrace | ||
| val hook = setUnhandledExceptionHook({ _: Throwable -> }.freeze()) | ||
| if (hook != null) hook(exception) else exception.printStackTrace() |
There was a problem hiding this comment.
It worth prepending the coroutine context and the fact that an app is terminated due to unhandled exceptions before calling exitProcess(-1)
There was a problem hiding this comment.
Hmmm.... I see that this PR is related to native and I am not concerned at the moment. Also I don't do mobile an don't know the details of setup, so my question might look stupid. But can we be sure that this change is confined to iOS? In other words, are we sure that kotlin native with coroutines will never be used for server side or desktop development? Because exitProcess(-1) seems too radical for me on the server, I would definitely hate it. Again sorry for stupid question.
There was a problem hiding this comment.
Your question raised an important issue that we're going to address, thanks for that!
It is indeed important to have an ability not to terminate an application on unhandled exceptions, but it also important to be able to do so.
KMM and iOS is our primary focus for now and there is only an API to do the latter, not the former.
So, in the 1.5.1-native-mt the default behaviour will be to crash (in the end, an unhandled exception in a coroutine is no different from the unhandled exception from main or a worker) for the sake of iOS apps. The workaround to avoid application crashes is not to leave exceptions unattended (e.g. by using CoroutinesExceptionHandler).
But in 1.5.30 (or in 1.6.0, it's being discussed right now) we'll provide a new K/N stdlib API that allows to invoke unhandled exception hook without termination (right now this API is supposed to be used only with the consecutive call to abort or exitProcess) and will provide an opt-in mechanism to set your own exception hook without crashing.
qwwdfsad
force-pushed
the
native-mt
branch
4 times, most recently
from
8df9c27 to
48cf2cf
Compare
|
Merged manually |
Fixes #2398