<@U2E974ELT> Can sealed classes play well with flo...

# coroutines

[plr]

@elizarov Can sealed classes play well with flows? Let me explain:
Imagine we want to create a flow which is transparent regarding exceptions. We have this sealed class to represent either a success of failure:

sealed class Result
data class Success(val image: Image) : Result()
object Error : Result()

class Image

And we have a suspending function to fetch an Image, which can throw an exception:

suspend fun fetchImage(url: String): Image {
    // Returns either an Image instance or throws an exception
}

So we wrap this nasty function in another function which we'll use in our flows:

suspend fun fetchResult(url: String): Result {
    return try {
        val image = fetchImage(url)
        Success(image)
    } catch (e: IOException) {
        Error
    }
}

Finally, we can use it:

val urlFlow = flowOf("url1, url2", "retry")
val resultFlow = urlFlow.map { url -> fetchResult(url) }

So far, so good.
However, out of curiosity, I tried to re-write the same flow above using the catch operator:

val resultFlow: Flow<Result> = urlFlow.map { url ->
    val image = fetchImage(url)
    Success(image)
}.catch { e ->
    emit(Error)
}

This code does not compile. I try to emit an Error from catch (even if it's a valid Result instance). The compiler says: "Type mismatch, required Success".
I know that it's because the inferred type of the upstream flow before catch is Flow<Success>.
But in my humble opinion, we should be able to write some similar logic with a flow of some super type, and FlowCollectors being able to emit subclasses of the sealed class.
Am I missing something?

[araqnid]

I think you have to simply force the map operator to produce a Flow<Result> rather than a Flow<Success>, e.g. urlFlow.map<Result> { … }

[Zach Klippenstein (he/him) [MOD]]

This isn't a flow issue. Any time a type is inferred from a value, the most specific type will be inferred.

[araqnid]

sorry, map takes two type parameters, it would have to be map<String,Result> { … }

[araqnid]

or you can write Success(image) as Result which I admit looks a bit weird

[Kroppeb]

Huh, are flows not covariant?

[plr]

Thanks @araqnid, that's what I was missing. I can't believe I didn't know I could do that with map.

[araqnid]

@Kroppeb they are: Flow<out T>

[araqnid]

I was wondering about that too. I thought that it should be possible to infer Result for that catch extension call, but apparently not.

[Kroppeb]

I don't understand why it doesn't

[Kroppeb]

Can you give Result as a type Param for catch?

[araqnid]

Ah yes, you can do that. That’s nice, it’s simpler that giving two parameters to map

[araqnid]

You can get it to infer automatically by defining a catch operator that’s a bit more restrictive:

fun <T> Flow<T>.catchAs(mapper: (Throwable) -> T): Flow<T> = catch { emit(mapper(it)) }

and then:

val flow = flowOf("x")
            .map { value -> Outcome.Success("It was $value") }
            .catchAs { Outcome.Failure(it) }

[Zach Klippenstein (he/him) [MOD]]

catch could handle this case if it had another type parameter. That might be worth filing/submitting a PR for (not just for catch, but in general).

The current signature is:

fun <T> Flow<T>.catch(
    action: suspend FlowCollector<T>.(cause: Throwable) -> Unit
): Flow<T>

But if it were this, then the compiler would be able to infer that T is Success but R must be the lowest-common-supertype of Success and Error, and your code would work as expected:

fun <T : R, R> Flow<T>.catch(
    action: suspend FlowCollector<R>.(cause: Throwable) -> Unit
): Flow<R>

There are probably a lot of operators that could use that pattern.

[Kroppeb]

The issue is that those are equivalent

[Kroppeb]

Cause it's flow<out T>

[Kroppeb]

So each flow<T> is also flow<R>

[araqnid]

I think the problem is because it’s trying to solve for T which is used both in Flow<T> and FlowCollector<T> in that signature, and of course it’s contravariant for FlowCollector, so they only allow one solution for T. As @Zach Klippenstein (he/him) [MOD] points out, if you expand it so they have different (but related) parameters, then it can solve it by varying T to a superclass.

[araqnid]

@Zach Klippenstein (he/him) [MOD] I’ve just tried it, but it doesn’t seem able to infer T and R if I define a catch extension like that. Not even if I try to give it a hint by assigning the result to a typed val of Flow<Outcome>

[araqnid]

(tried both with and without new inference)

[Zach Klippenstein (he/him) [MOD]]

Hm, maybe i messed up the bounds – i’m pretty sure I’ve used that trick in similar cases to solve this problem. Oh, i think the lambda needs the @BuilderInference annotation now, since it’s actually doing active inference.

[araqnid]

hmm, still no joy; tried annotating it on the extension function and the collector parameter.