How can I manage Error in coroutines in case of AP...

# coroutines

[Aslam Hossin]

How can I manage Error in coroutines in case of API requesting? Using RxJava, we can easily manage error in onError operator. I want to know is there any operator like RxJava

[zak.taccardi]

`try`/`catch`

[Mark Murphy]

for example, suspend functions just throw ordinary exceptions, and you catch them using standard Kotlin `try`/`catch` when you call the suspend functions

[Aslam Hossin]

I know `try`/`catch` block catch the exception, but I want to know about coroutines operator like onError, doOnError. Is there any support like these ?

[Ilmir Usmanov [JB]]

runCatching { ... }.onFailure { ... }

[gildor]

Which is not better imo than try/catch

[gildor]

Instead of operator, why not just use standard if/else and try catch?

[Joaquim Ley]

Agree with you, just use try/catch just because it’s oldschool doesn’t mean you can’t use it. 🙂

[Aslam Hossin]

I want to add a compose for handling all error from one method than using `try`/`catch`. How can I do it? That's why need an operator.

[Dico]

inline fun handleErrors(block: () -> Unit) = try {
    block()
} catch(ex: MyError) {
    handleError(ex)
}

[Marcelo Hernandez]

Just keep in mind that catching Throwable also catches the CancellationException which typically should be propagated as part of the Coroutines cancellation mechanics.

[Marcelo Hernandez]

RxJava doesn't onError when disposing an active Single.

[Marcelo Hernandez]

Coroutines kind of force you to catch the specific exceptions.

[Zach Klippenstein (he/him) [MOD]]

@Aslam Hossin I think you’re looking for the catch operator:
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/catch.html

[Zach Klippenstein (he/him) [MOD]]

onCompletion might come in handy too if you need finally semantics:
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/on-completion.html

[Mark Murphy]

note that those are for Flow

[Zach Klippenstein (he/him) [MOD]]

Ah, given the bolded references to RxJava I assumed we were talking about Flow 😅 My bad.

[gildor]

I want to add a compose for handling all error from one method than using `try`/`catch`.

Why you cannot do this with try
/catch?

[Aslam Hossin]

The presence of the try-catch block imposes overhead when no exception occurs. That's why I want to avoid `try`/`catch`.

[gildor]

No, it doesn’t

[gildor]

It’s very-very optimized, it’s a feature of JVM, not even some language abstraction

[gildor]

Also, how do you think Rxjava (or any other library) catches those errors in operators? %)

[Aslam Hossin]

@gildor Thanks for your informative reply.

[Aslam Hossin]

@gildor, As far as I know, there is no significant performance impact on try block but in catch block greater impact becomes.

[gildor]

of course, catch creates Exception with stacktrace, which relatevely heavy object

[gildor]

but you cannot avoid it, anyway you have to create exception, you can of course reuse some existing exception, but it will not have any stacktrace, which make it mostly useless

[gildor]

and again, it’s exactly what happening in all operators

[gildor]

But this is the reason why it’s called “Exception”, it shouldn’t happen during regular invocation flow, it should be some exceptional case, this is one of the reasons why it’s not recommended to use exceptions to control invocation flow

[Aslam Hossin]

@gildor I got it, thank you so much.

[Zach Klippenstein (he/him) [MOD]]

Fun fact: As an optimization, some of the exceptions used internally for cancellation in Flow operators disable stack trace collection, which I believe is where almost all of the exception-related overhead comes from.

https://github.com/Kotlin/kotlinx.coroutines/blob/65f1eafbb42f43f7d236048ceb2f2ec4f1291362/kotlinx-coroutines-core/jvm/src/flow/internal/FlowExceptions.kt#L9-L13