For catching exceptions with coroutines with the u...

# coroutines

[kenkyee]

For catching exceptions with coroutines with the usual:
catch (exception: Exception)
What do people go about lint flagging this as too generic an exception? Just suppress the warning all the time? 🙂

[gildor]

But it’s exactly the same for non-coroutine code. How do you handle this usually?

[kenkyee]

catch only the specific type of exception...not add a catchall

[kenkyee]

though in Rx, you subscribe and use the 2nd param for the error handler

[gildor]

catch only the specific type of exception...not add a catchall

So, why cannot you do this for Coroutines?

[gildor]

though in Rx, you subscribe and use the 2nd param for the error handler

Which is exactly what catch (exception: Exception) is, catch all the Throwables, I don’t see any difference. So or use this approach and disable this check, or use specific exception type

[elizarov]

If you want Rx-style “catch all” without lint check complaining, we now have Rx-style “catch all” and functional exception handling for you!

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

🧌

[kenkyee]

It's mostly for lint check avoidance...i.e. Lint says this is bad practice. All the examples say do it anyways 😂
Thanks for the runCatching...is that the same as launchCatching? Or asyncCatching?
Basically looking for a consistent coding guidrline that's similar to the Rx technique where we log exceptions and/or handle them.

[kenkyee]

BTW, the lint check is good IMHO. Catching broad exceptions is generally bad practice so for coroutines, we'd have to add a suppression line each time we use it if that's standard practice..

[gildor]

Looks that those 2 messages are contradict each other

consistent coding guidrline that’s similar to the Rx technique

This is exactly as catch (exception: Exception), Rx just doesn’t have easy way manage it (as coroutines) so Rx practice: catch all the exceptions

Catching broad exceptions is generally bad practice

Which is true, but this is true for coroutines or for any other code, there is no difference

I don’t think that coroutines should force some specific exception handling practice, just because you can use any approach that you prefer for your other code

[gildor]

also practices could be different depending on project type.
If for example on backend it’s fine to do not catch broad exception types to easily find them in logs and fix later, for UI application you usually want to catch everything on top most level and manage such problems without app crashing

[kenkyee]

"don’t think that coroutines should force some specific exception handling practice"
No disagreement there. It's mainly for the lint warning and adding @Suppress() everywhere 🙂
For Rx, we have team coding guidelines....specifically, all .subscribes should include a call to a util method that wraps the exception so we get a useful stacktrace instead of a useless trace of Rx methods. I'm trying to come up w/ a set of coroutine guidelines before we add that to our app...