мне в принципе достаточно такого варианта. Просто интересно стало почему api флоу не даёт сразу эксепшен заемитить. Либо после rx непривычно

А какое поведение вы ожидаете? Что оно на коллекте затроувится?

несколько приватных источников данных, один публичный для клиента (флоу). Один из приватных отвалился, нужно сообщить что пошло не так. Помоему популярный кейс

Это не поведение, а кейз

а поведение, да, желательно не в коллекте, а в блоке catch исключения обрабатывать. и не оборачивать в result

В блоке кетч где?

флоу

Что флоу?

В любом случае устройство флоу очень простое в своей базе и думаю это было бы усложнением возможно неоправданным, если учесть, что у каждого тут может быть своё видение как нужно такой заэмиченный эксепшн обработать и где. Усложнились бы реализации операторов для флоу и общий подход, возможно создатели флоу посчитали, что оно просто того не стоит

Простота с которой реализован флоу реально вызывает восхищение, на два порядка проще чем рх. Думаю, это дорого стоит и терять такое преимущество без необходимости особенной вряд-ли кто-то стал бы

согласен. Благодарю за развернутый ответ. Хотя с другой стороны у Continuation есть resumeWithException

Ну да, но флоу это же не континуация

Люто плюсую
Флоу даёт простую возможность реализовать какой-то реактивный кейс по своему, не заставляя использовать какие-то костыли с кучей встроенных операторов как иногда происходит в рх

Это не корутина

я понимаю, просто есть аналогия пришла на ум. .Собственно вопрос снят. Я за простоту также как и все :)

Посмотрите на исходники операций, они очень простые и вам думаю многое станет понятно

При этом вы можете кинуть исключение в эмиттере 🙈

Три основных отличия:
0. В случае с наллабилити реже приходится боксить значения. T? и T -- одно и то же в представлении JVM (кроме случая примитивов, конечно), Optional -- бокс.
1. T является подтипом T?, но T не является подтипом Optional<T>. Соответственно в функцию, ожидающую опшнл, нельзя засунуть объект без заворачивания, с наллабилити аналогичное прокатывает. Та же фигня актуальна, к примеру, для экстеншнов на наллабл ресиверах.
2. С помощью опшнлов возможно выразить Optional<Optional<T>>, но T? и T?? -- это одно и то же. В очень редком случае вроде необходимости выразить в джейсоне отдельно наличие значения, отдельно налл, отдельно отсутствия, в варианте с наллабилити придётся что-то придумывать.

Стоит ли последнее того, чтобы юзать опшнлы -- решать вам, конечно :)

Ну и да, если б в языке были тайпклассы, у опшнла было бы ещё одно преимущество, но в котлине это неактуально.

Asynchronous Flow - Kotlin Programming Language
https://kotlinlang.org/docs/reference/coroutines/flow.html#flow-exceptions

Вот тут есть про то как обрабатывать исключения