Is there a function on `CoroutineScope` which is `...

# coroutines

[lukaswelte]

Is there a function on CoroutineScope which is onError? So in case any of the coroutines in the scope are cancelled or failing it will not cancel the parent scope routines, but instead invoke the error handler. Or is try-catch around the coroutineScope {} currently the only way?

[elizarov]

There is CoroutineExceptionHandler that does it. It is explained here: http://kotlinlang.org/docs/reference/coroutines/exception-handling.html

[lukaswelte]

Thanks, but if I have an async function (so I wait for an answer), I would need need a fallback in addition instead of just catching the exception

[dekans]

async provides a Deferred, which can tell you if an exception occured

[lukaswelte]

As an example: https://pl.kotl.in/rk9ZlXAcQ

I want that startFetching in this example is not cancelling the parent scope and would like to not have try-catch around the startFetching call, but rather something like

val x = startFetching().ifError { emptyList() }

[dekans]

CoroutineExceptionHandler seems a good tool for you then

[elizarov]

You can easily write this ifError function as an extension.

[elizarov]

fun <T> Deferred<T>.ifError(defaultValue: () -> T): Deferred<T> = GlobalScope.async { 
    try { await() } catch(e: Throwable) { defaultValue() }
}

[elizarov]

But I highly recommend to reconsider the whole design. Writing functions that return Deferred is generally a bad idea from the design standpoint. You should design your API using suspending functions, so that you fetching function looks like suspend fun fetch(): T, for example

[lukaswelte]

Thank you both, I’ll rethink and prepare a better example (although example does not use Deferred<T> but T as response)

[elizarov]

In this case Kotlin 1.3 already has the extensions you need:

[elizarov]

Write:

runCatching { startFetching() }.getOrElse { emptyList() }

[elizarov]

But this is not a good design, either, since it ignores all exceptions. So if you have a logic problem somewhere inside your startFetching code, you’ll never know about that.

[lukaswelte]

runCatching is nice. Thank you for your thoughts.

I’ll create my own little function which will catch the exception, report/log it and then return the fallback.

[kingsley]

Perhaps supervisorScope or SupervisorJob might also be something to consider for this use case