https://kotlinlang.org logo
#coroutines
Title
# coroutines
k

kenkyee

11/16/2018, 1:08 AM
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? 🙂
g

gildor

11/16/2018, 2:18 AM
But it’s exactly the same for non-coroutine code. How do you handle this usually?
k

kenkyee

11/16/2018, 3:08 AM
catch only the specific type of exception...not add a catchall
though in Rx, you subscribe and use the 2nd param for the error handler
g

gildor

11/16/2018, 4:11 AM
catch only the specific type of exception...not add a catchall
So, why cannot you do this for Coroutines?
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
e

elizarov

11/16/2018, 7:03 AM
If you want Rx-style “catch all” without lint check complaining, we now have Rx-style “catch all” and functional exception handling for you!
Copy code
runCatching { ... }.onFailure { ... }
🧌
❤️ 1
k

kenkyee

11/16/2018, 11:38 AM
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.
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..
g

gildor

11/16/2018, 11:52 AM
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
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
k

kenkyee

11/16/2018, 2:41 PM
"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...
3 Views