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

Miguel Vargas

04/26/2020, 5:05 AM
One thing that was nice about rxjava is that it forced you to consider the error path. I’m finding that this is a big problem with coroutines especially since kotlin doesn’t believe in checked exceptions. When making a network call one should always handle the error path, with coroutines it’s easy to forget since it’s purely optional. Any ideas how to remind developer to always wrap network calls in try/catch and handle the ioexceptions?
b

Bhullnatik

04/26/2020, 5:49 AM
Unfortunately Kotlin doesn’t have checked exceptions, so not possible with only code but you could use a custom linter to check for that
o

Orhan Tozan

04/26/2020, 11:48 AM
We moved from using exceptions to returning a value object like Result.success Result.failure
c

cypher121

04/26/2020, 12:00 PM
Result would be my solution to this as well. Not only are you forced to handle errors with it, but the errors take the same code path as success does, instead of jumping to catch blocks and/or throwing them up the call stack like exceptions do
s

streetsofboston

04/26/2020, 3:56 PM
I second the ideas of the previous two messages. If exceptional results are important to your business logic, use cases, consider functional data types such as Result, or even better ones such as
Either
or
IO
(see the Arrow library for Kotlin).
m

Miguel Vargas

04/26/2020, 10:00 PM
Having to remember to wrap a network request in a Result object seems like the same thing as having to remember to wrap it in try/catch.
t

taer

04/27/2020, 12:04 AM
I've been noticing with flows though that it kinda is in conflict w/ "result" sealed class types. There are helper flow functions like
retry
that will retry your upstream on exceptions(not results). Also, I'm not 100% sure, but you probably want to make sure if you do put the results in a success/error sealed class, that you don't catch CancellationException. I could be wrong on that part though
But this method https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/retry.html wants your flow that's emitting to throw exceptions for it it work
But at the same time, I love the sealed classes for networky type operations.
e

elizarov

04/28/2020, 6:38 PM
Submit an issue for value-catching version of
retry
if you have a use-case for it please.
4 Views