Shocker.ProskyANA,

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

hVosttskyANAна практике код не кишит if...else, нет шквала проверок
так как действительно мало, что можешь сделать, да и не требуется

Ну это понятно, что на практике вызовов мало, что это проблемы не вызывает.
Для наших микро-сервисов мы используем Swagger и AutoRest, который генерит
низкоуровневый API клиент, т.е. именно OperationResult. Его использовать напрямую
неудобно. Даже если вызовов мало, это требует большего контроля со стороны
разработчиков, поэтому пишутся высокоуровневые обёртки, которые во-первых
убирают прямую зависимоть от конкретного генератора, и скрывают подробности
реализации. Потребители не знают, что там, REST, SOAP или что-то ещё.

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

Вот отвалился микросервис, то есть к примеру operationResult.Success - false, operationResult.StatusCode - TransportFailed, operationResult.Exception - все подробности о произошедшем
И что ты будешь делать?
Кидать своё исключение, куда завернёшь operationResult.Exception?
При отвал отдельного микросервиса не должен приводить к отвалу системы в целом.
То есть надо перехватить своё же исключение и, грубо говоря, завернуть предварительно залогировав.

Не, ну можно конечно, но по мне так оверхед.

Алексей КskyANAКидать своё исключение, куда завернёшь operationResult.Exception ?Да хоть в самодельное свойство, хоть в InnerException...
Да понятно, но зачем?

hVosttskyANAКидать своё исключение, куда завернёшь operationResult.Exception?

Ну Inner-же..
Да понятно, но зачем?

Алексей КskyANAТо есть надо перехватить своё же исключение и, грубо говоря, завернуть предварительно залогировав.Зачем? Логирование, стандартно, организовать где-нибудь на уровне системной библиотеки, используемой для коммуникации (WebAPI, WCF и т. п.).
Вот я и говорю: Зачем?

hVosttskyANAВот отвалился микросервис, то есть к примеру operationResult.Success - false, operationResult.StatusCode - TransportFailed, operationResult.Exception - все подробности о произошедшем
И что ты будешь делать?

Ну во-первых, высокоуровневое API, может сделать что-то исходя из того, что работает с OperationResult, может попробовать ещё раз, или использовать другое подключение или что-то ещё.Хм, пишешь декораторы Circuit Breaker и Retry, при конфигурации IoC контейнера указываешь, что использовать.

hVosttПотребитель высокоуровневого API ожидает, что операция будет выполнена точно также как любой вызов любого интерфейса в проекте. А если вызов не удался, по любым причинам, то сломаться должна вся цепочка, вплоть до прикладного кода, и где-то должно перехватиться исключение, чтобы вернуть систему в изначальное состояние, удалить какие-нибудь временные файлы, откатить транзакции и т.д. и т.п.Зависит от.
Отвалился Couchbase, ну и фиг бы с ним, там кэш. Лезем напрямую в БД.
Чуть медленнее получим данные, но зато пользователи продолжают работать.

hVosttДля чего потребителю знать Success или не Success?Тупо для того, чтобы понять по какой ветке идти.
В случае с кэшем для того, чтобы понять получил ты нужные данные, или надо в БД лезть.

hVosttПросто я пока не понимаю, в чём профит работать с OperationResult повсеместно, а не на стыке (низкоуровневый API клиент). А также, ты предлагаешь жить теперь с двумя механизмами обработки ошибок: с исключениями и OperationResult, или уже вовсе от исключений отказываться совсем и перехватывать их везде и всегда, чтобы затолкать в свой OperationResult, привет двухтысячные, как по мне.Не не, я пока не предлагаю это делать повсеместно

hVosttskyANAТо есть надо перехватить своё же исключение и, грубо говоря, завернуть предварительно залогировав.

Да, но отлавливать ты его можешь через множество вызовов с раскруткой стека, допустим, на уровне модуля, или приложения. И фильтровать исключения, какие ты можешь обработать по месту, а какие нет.Опять же рассмотрим случай с кэшем.
Ну зачем мне там кидать свои исключения, чтобы потом их ловить?
С кэшем проблемы (operationResult не Success) - идём в БД.

hVosttskyANAДа понятно, но зачем?

В смысле, зачем? Давай вот такой пример. Распределённый кеш.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache?view=aspnetcore-2.1

Ты считаешь, что интерфейс спроектирован не лучшим образом, и методы типа Get(String) должны возвращать OperationResult, ведь очевидно, что реализация будет скорее всего использовать сетевые API, откуда будут приходить структуры, содержащие значение, статус выполнения и прочее?
Не, с этим всё в порядке, а вот DistributedCache.Client пусть возвращает OperationResult

hVosttskyANAНе, с этим всё в порядке, а вот DistributedCache.Client пусть возвращает OperationResult

Ну дык, об этом и речь. А как иначе?
О, консенсус! За это надо выпить

hVosttТем более, кеш может использовать интенсивно, а проверки результата сильно увеличивают связанность.
Вот этого не понял...

Связность характеризует то, насколько хорошо все методы класса или все фрагменты метода соответствуют главной цели, - иначе говоря, насколько сфокусирован класс © Макконнелл, 2010.

О чём ты?