Surely it was discussed many times, how does your error handling look like? Assuming Retrofit+coroutines setup. Do you go: a) old-fashioned exceptions: return pure type, use try/catch, separate stream of errors in rx, etc. or b) trendy FP style: return wrappers like

Either/Try/Result

If you go

b)

, since you can't use kotlin

Result

type, do you bring Arrow for that? Do you create your custom

Either/Try/Result

? How does it look like?

I guess is a matter of code styling but I prefer B. Even when using RxJava I like using

onErrorReturn

,

onErrorResumeNext()

kind of operators to convert the Exceptions into something I can handler easier. Also I don't like the fact of having the 2 streams(Success and Failure) separate. What do you mean by:

since you can't use kotlin Result?

What stops you?

I throw but im not happy about it. Also not happy about when(result) everywhere

@Pablichjenkov Isn't kotlin

Result

forbidden as return type? @ursus Why not happy? Too easy to forget to handle the exception?

yea

There were plans to add complie time warnings when the exception is not handled. Also, apparently there is this

@Throws

annotation, but it's more for interop tho.. Funny, that Swift decided to go with checked exceptions and Kotlin removed them 🙂.

yea im torn. another solution would be to go full FP, but thats not going to fly in a team

@ghedeon It is prohibited now because the API may potentially change in the future. However, you can create your own `Result`(same name) class and copy and paste the full internal class in it. When the internal got release then just delete yours.

We created a Try type, and have an extension function on Result to convert it. So we can do something like:

runCatching {
     blahblah()
}.toTry()

@mattinger how do you use the Try? when over it or flatmap etc?

"Also not happy about when(result) everywhere"

I don't mind calls to when. Ideally, you'd only need them at some terminal location. When used properly with something like a sealed class, it becomes very verbose and easy to read. My philosophy is that whenever we encounter an error, ultimate something needs to be passed back so that the user can make a decision about what to do next. After a lot of thought and trial and error, I wrote a short blog post on that reasoning. https://ntxdroid.com/we-are-in-flight

@ursus generally with a fold method, though one could use when (which is how the fold is implemented)

yea but that buys into FP fully