Surely it was discussed many times, how does your ...

# android-architecture

[ghedeon]

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?

[Pablichjenkov]

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?

[ursus]

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

[ghedeon]

@Pablichjenkov Isn't kotlin Result forbidden as return type?

@ursus Why not happy? Too easy to forget to handle the exception?

[ursus]

yea

[ghedeon]

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

[ursus]

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

[ursus]

I still not conviced that removing them was a good idea, since, to me its same analogy as with explicit nullable types. I see the question mark, i know, compiler makes me handle things etc. I see throws clause, compiler makes me handle it

[Pablichjenkov]

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

[Pablichjenkov]

The downside of this approach is that you got to keep on top of the internal Result class changes to be aligned with them.

[Pablichjenkov]

Also check this:
https://stackoverflow.com/questions/52631827/why-cant-kotlin-result-be-used-as-a-return-type
You can provide a compiler flag: -Xallow-result-return-type if you want to use it experimental

[mattinger]

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

runCatching {
     blahblah()
}.toTry()

[ursus]

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

[Al Warren]

"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

[mattinger]

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

[ursus]

yea but that buys into FP fully

[ursus]

@Al Warren looks nice but what I dislike about the sealed class return types, is that you need to repackage it per every method, or somehow nest them, no, not sure about that Either<T, Throwable> is going to be more easily used in general

[ursus]

then again having general Throwable is not amazing either, since you need to go through source to see what kinds of errors it contains to when over them