One thing that was nice about rxjava is that it forced you to consider the error path. I’m finding t...

# coroutines

[Miguel Vargas]

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?

[Bhullnatik]

Unfortunately Kotlin doesn’t have checked exceptions, so not possible with only code but you could use a custom linter to check for that

[Orhan Tozan]

We moved from using exceptions to returning a value object like Result.success Result.failure

[cypher121]

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

[streetsofboston]

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).

[Miguel Vargas]

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.

[taer]

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

[taer]

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

[taer]

But at the same time, I love the sealed classes for networky type operations.

[elizarov]

Submit an issue for value-catching version of retry if you have a use-case for it please.