Marko Mitic
11/04/2019, 1:44 PMrunCatching
that doesn't catch CancellationException
?
Would be nice to have some standardized solution (and IDE warnings on catching the CancellationException
in coroutines)runCatching
but it can't return kotlin.Result
because it's inline class 😞louiscad
11/04/2019, 2:43 PMMarko Mitic
11/04/2019, 2:44 PMlouiscad
11/04/2019, 2:44 PMkotlin.Result
specifically?Marko Mitic
11/04/2019, 2:46 PMrunCatching
that won't catch CancellationException
. Ideally, it would be a simple update to codebase, ideally returning same typekotlin.Result
gildor
11/04/2019, 2:48 PMMarko Mitic
11/04/2019, 2:49 PMgildor
11/04/2019, 2:50 PMlouiscad
11/04/2019, 2:52 PMkotlin.Result
, even with the flag activated (unless they add a mechanism to prevent compilation of such things, which is still breaking things and delaying update until library updates)Marko Mitic
11/04/2019, 2:55 PMpublic inline fun <R> coRunCatching(block: () -> R): Result<R> {
return try {
Result.success(block())
} catch (e: CancellationException){
throw e
} catch (e: Throwable) {
Result.failure(e)
}
}
louiscad
11/04/2019, 3:12 PMResult
, right?Marko Mitic
11/04/2019, 3:13 PMlouiscad
11/04/2019, 3:14 PMgildor
11/04/2019, 3:17 PMMarko Mitic
11/04/2019, 4:15 PMkotlin.Result
, so that updating current code to coRunCatching
is just changing name of fun called.louiscad
11/04/2019, 4:32 PMcancellableRunCatching
, which IMHO is more accurate and makes it more obvious why it's used in place of stdlib's runCatching
without having to look at the source of the function (which is impractical if not viewed from an IDE with checked out revision, like on VCS UIs or in-IDE diffs).