Интересно, юзал кто-то резалт монады, например https://demystifyfp.gitbook.io/fstoolkit-errorhandling ?) Мы тут

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

FYI в OCaml это решается через polymorphic variants https://keleshev.com/composable-error-handling-in-ocaml

Я юзаю почти с момента создания. В основном на базе job. Часто используются модификации с переписанным Run. В UI как правило дистанции очень короткие, поэтому ошибки по месту преобразуются либо в строки, либо в промежуточные типы необходимые для запихивания в UI. Т.е. к тексту добавляются иконки, особенности отображения, вплоть до контролов, а также действия пользователя позволяющие решить проблему на основе замкнутых данных. Так что проблемы не чувствуется. В БЛ или комбайнах общего назначения, когда начинают смешиваться ошибки разного уровня нам либо хватает Choice, либо таки пилим отдельные типы. Это дорого, поэтому сразу возникает вопрос, а не слишком ли растянули коммуникации. Если речь идёт об ультимейт методе, к которому будет сведено всё существование либы, то стерпится. Если речь про пересобираемый трансформер, то скорее всего произошёл проёб в архитектуре. // Плюс для геморройных случаев возможны билдеры, что на "плохие" ошибки уходят к подвязанным хендлерам, получают от них заглушку в виде "хорошей" ошибки нужно типа и радостно бегут к выходу. Исходная "плохая" ошибка полноценно разбирается в хендлере, и как правило на основе особенностей задачи. Универсальные решения мне неизвестны. Но всё это бегает на нарощённом гопаке. Понятия не имею, в какой это рокетсайнс может превратиться, если пытаться сидеть на стандартных средствах.

сорри, я перечитал несколько раз, но так и не понял что ты предлагаешь) ситуация простейшая - есть две функции x1 и x2, которые обращаются к трем функциям, первый к f1 и f2, другой к f2 и f3, каждая функция может кинуть свою ошибку т.е. есть Err1, Err2 и Err3. Если у x1 будет свой DU с ошибками, а у x2 свой, то они в будут друг с другом не совместимы для резалт монад. Соответственно выходит что Err1, Err2, Err3 должны лежать в одном DU, чего хотелось бы избежать

Ты спросил, кто юзал. Я ответил и частично объяснил почему нас эта проблема не особо касается. Что в твоём случае делать, понятия не имею. Абстрактная задача требует общего DU. Если не устраивает, ищи решение в особенностях своей задачи. Здесь тоже что и с попытками оптимизации. Можно дрючить массивы, а можно проследить перемещение данных и грамотно накидать счётчиков/кешей/и т.п., чтобы быть готовым к своей квери.

ну я не очень понял почему вас не касается - у вас не бывает вложенных асинкрезалтов? а если бывает, то там сидят строки в ошибке?

а чем это плохо? (когда строки в ошибке сидят)

Поверх навернуть глобальный список кодов ошибок, из BL летит контейнер, содержащий код ошибки и Content, где болтается уже сериализованная ошибка, которую можно поднять по коду. Громоздко конечно-но похожую хрень в тырпрайзе шарповом лепили, работало.

Бывает, просто вовремя утилизируем конкретные типы через уход в общий тип.

под "сидят строки в ошибке" ты вот такое понимаешь: Result<??'1, string * ??'2> ??

много чем плохо) нельзя exhaustive match сделать, потом строки влазят в бизнес логику, потом в ошибке часто приходится данные передавать дополнительные данные

Result<'T, string>

про строки написал) лучший вариант что я знаю это эксепшнов насоздавать и матчить, но exhaustiveness придется оставить

Не, из Content можно десериализовать ошибку и дальше матчить

Функция которая на самом верху (которая вызывает все другие) должна иметь свой DU Errors и мапить Errors из дргих функций в свой DU с помощью Result.MapError

а вот так: type Errors = |X1f2 |X2f2 type MyResult<'T1,'T2> = Result<'T1, Errors * 'T2> ??

ну вот таких "верхних" функций могут быть десятки, если вложенность большая) и там десятки подручных душек и маперов

крутая статья, ровно то что я просил, и даже ишуй у нас есть) https://github.com/fsharp/fslang-suggestions/issues/40 который в итоге ведет на ерэйзд