kotlinx.coroutines: Flow error handling and launchIn

… are we trying to simulate try/catch instead of using it?

Yes. The goal is have more concise and more composable way to do try/catch/finally so that, for example, you can encapsulate error handling logic specific to your application as a flow operator and reuse it everywhere in a declarative way.

Generally, using “bare” try/catch/finally in Kotlin is not very idiomatic. It is kind of “low-level” primitive that you usually find encapsulated inside higher-level operations. So far, coroutines are missing those “high-level” error-handling operations so you have to use try/catch/finally and the resulting code just looks “out-of-place” – a piece of imperative error-handling in sea of declarative code.

Is the order in which onError and onEach must be written enforced by onError returning a different type than onEach? Or is there another way the order can be enforced by the compiler.

I don’t see any easy way to enforce an order and I don’t see why it needs to enforced. It’s like try/catch. You catch error in the code in the above try block. We can tweak the naming to make “modifying” nature of onError more explicit. We can even use catch (instead of onError) and finally (instead of onCompletion):

responseDataFlow()
    .onEach { updateDisplay(it) }
    .catch { e -> showErrorMessage(e) }
    .finally { enableActionButtons() }
    .launchIn(uiScope)

(If go with this naming, we need to change the names of all the other onErrorXxx operators for consistency)

Note, that you can use “error catching” operators multiple times to catch errors in differents parts of the flow:

flow
    .catch { e -> ... } // catch flow errors
    .map { first(it) } 
    .catch { e -> ... } // catch first(it) failures
    .map { second(it) } 
    .catch { e -> ... } // catch second(it) failures
    .collect { ... } // do something with elements, can also use launchIn

catch doesn’t terminate the downstream flow. It gets a FlowCollector and can emit zero, one, or more values in response to an exception. It can also rethrow exceptions just like a regular catch block. This is already much simpler than the RxJava API which requires multiple operators to do these things. E.g. onErrorReturnItem(foo) is catch { emit(foo) }. onErrorResumeNext(fooObservable) is catch { emitAll(fooFlow) }.

Flow solves a very specific problem: working with asynchronous streams of data. Treating everything as such streams is one way to write a reactive application, but it’s not the only way. I think it’s become the popular thing to do for Android because RxJava was much nicer to work with and compose than a bunch of simple callback APIs, but in a lot of cases simple coroutine features are nicer still. As @louiscad said, you can still use all the other, simpler coroutine APIs when the functionality they provide is all you need. However, there are times when you actually have a stream of data, and in those cases you want something as expressive and powerful as Flow or Reactive Streams. Every app is different, choose an architecture that makes sense for your app.

Plus I don’t see how these proposed APIs are more composable than plain try/catch/finally? Why just not Try<T> or Result<T>?.

if someone needs flow operator which handles errors globally there is no need extra catch finally onNext it’s now possible to write it simply:

fun Flow.withErrorHandler() = flow {
  uiScope.launch {
    try {
      collect { emit(it) }
    } catch (e: Exception) {
      showErrorMessage(e)
    } finally {
      enableActionButtons()
    }
  }
}

also

responseDataFlow()
    .onEach { updateDisplay(it) }
    .launchIn(uiScope)

When and why this should be used instead of just launch(Dispatchers.Main) { collect { updateDisplay(it) } } ?

Flow / Streams in general is not a simple task to understand for a new programmer and by adding multiple ways to accomplish the same thing in the library makes more difficult to learn new concepts.

Ps. when we’re thinking in stream as a kind of streams of transformations (filtering, mapping) then APIs as onNext, onError looks like out of place.

I understand that for current Android Java-ish developers this is cool and nice and it’s similar as RxJava, but please review this design and look for more opinions which are not affected by RxJava / Android users, at least defer it for later.

Pps. these are not stream operators they are not working on items on stream, but just are “terminating” callbacks. And stream (Flow) is designed for sequences of items not for a single item.

@antanas-arvasevicius see https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/run-catching.html

Maybe I’m missing something, but why are we trying to simulate try/catch instead of using it? Ex: your ui code could be

uiScope.launch {
  try {
    responseDataFlow().collect { updateDisplay(it) }
  } catch (e: Exception) {
    showErrorMessage(e)
  } finally {
    enableActionButtons()
  }
}

I mean, maybe the proposed operators would be useful in other situations, but for the ui use-case this seems way more clean too me.

Agree with @streetsofboston, I think this inconsistency could potentially be confusing:

• onEach and onCompletion are both just for performing side effects - they don’t transform the source flow in any way.
• onError, by default, doesn’t just allow performing side effects but also consumes the exception. This is more consistent with try/catch (where you need to explicitly re-throw) but inconsistent with the other two on* operators.

I would rather keep onError just for side effects, and calling the proposed operator something like catchError. Although I don’t think this operator is actually needed at all, its use cases are all covered by onErrorCollect already (implement onErrorReturn, rethrow a different exception, etc.).

Notice how onError is written after onEach to resemble the regular try/catch code.

Question: Is the order in which onError and onEach must be written enforced by onError returning a different type than onEach? Or is there another way the order can be enforced by the compiler.

If the order cannot be enforced, I’m a little worried about coding mistakes that are easy to make but hard to figure out.