Hello all. We make extensive use of flows and will...

# coroutines

[Victor Rendina]

Hello all. We make extensive use of flows and will allow exceptions to be thrown into a flow to notify downstream consumers that a problem has occurred. We have recently been noticing some crash reports where the stacktrace indicates the location that the exception was constructed in the flow, but not where the collector is that received the exception.

Typically we will handle exceptions by applying a catch {} operator to the flow near the collection site, but it seems in this case we have not added a catch and are having difficulty determining exactly where the collector is that initiated the exceptional flow. Does anyone have any advice about how to trace the site of the collector that received the exception?

[louiscad]

I use the "Find usages" feature to track down the one that isn't calling the catch operator

[Victor Rendina]

Yes, it is a good suggestion, unfortunately these flows are often combined with other flows, mapped, etc. before they ultimately arrive at a collector

[louiscad]

Should catch appear before or after combining?

[louiscad]

Have you considered using an algebraic type for success and error cases (i.e. a sealed interface/class hierarchy), or simply kotlin.Result to avoid exposing throwing flows?

[Victor Rendina]

Yeah we use algebraic types for suspending functions that return a single result, we found using them inside of flows was pretty clunky when you try to transform the flows. It works really well though for single values and is a good suggestion.

Our typical setup is to have some flows that return information from a data layer collected by view models in the UI layer, the catch statements are usually placed at the UI layer so the appropriate actions can be taken for the UI in the event of a failure.