skyANA,

tight coupling

skyANAВсё равно не понял. Тебе так, или иначе надо проверять результат, что вернулся из кэша.

Для потребителя значение либо есть в кеше, либо нет. Остальное, либо ошибка, либо какая-то скрытая обработка.

skyANAТо есть если DistributedCache.Client возвращает operationResult.Success, то берём operationResult.Value и используем.
Не Success - идём в базу. При этом не надо тут генерировать никаких исключений и героически их обрабатывать.

В 1000 мест мне нужно работать с кешем и в 1000 мест я вынужден проверить Success. Но с кешем понятно, это не критичный участок, а если это распределённое файловое хранилище, например. Мне нужно получить или сохранить файл, очень много где, зачем мне этот OperationResult, мне удобно работать с файлами, как с System.IO, ошибки путь сваливают весь код, ибо он не имеет смысла без файлов, и ничего нельзя сделать.

skyANAИ откуда ты взял эти 1000 мест?
Пишется декоратор и ты работаешь с repository, или query как обычно, просто при конфигурации IoC контроллера указываешь, что заверните-ка мне это в CacheDecorator.

Ну мы уже выяснили, что таки делаем декоратор, и при ошибках бросаем исключения, если это требуется. Если компонент не влияет критически на работу приложения, то ошибки игнорируются, например, для кеша Get отдаёт всегда null, а GetOrAdd возвращает значение из переданной фабрики.

skyANAРабота с файлами тоже разная бывает.
К примеру пользователь заливает js под видом картинки.
Можно кинуть ему исключение "Нельзя, козлина!", героически его поймать и вывести "Ай, ай, ай".
А можно operationResult.StatusCode = StatusCode.NotAllowed.

А вот здесь ты как раз путаешь валидацию с ошибками. Попытка внести данные, нарушающие целостность СУБД, это ошибка. При чём ошибка программиста, который не удосужился проверить данные перед тем, как их сохранять, не обеспечил условия. Здесь так же. Если же даже после валидации ошибка возникла, то это исключительная ситуация, которую не нужно пытаться свести к валидации и показывать пользователю.

skyANAНо сваливать весь код уж точно не стоит

Стоит, так как программист не выполнил нужные действия, значит это надо чинить.

skyANAhVostt,

короче бессмысленный какой-то спор Всё зависит от ситуации, архитектуры приложения и требований.

Ну почему. При выставлении API наружу, механизм исключений не будет работать, поэтому ты упаковываешь результат в OperationResult.

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

Как бы понятно, it depends, но ключевые тезисы никто не отменял :)

skyANAНу убедил it depends

Как раз недавно рефакторили модуль, отвечающий за исполнение DSL. Все вызовы были построены на OperationResult (да-да, мне тоже раньше это казалось офигенно крутой идеей). Переделали на исключения, речь идёт именно про ошибки. Кода стало меньше, чище, понятней и решили пару проблем.

LRЗнакомо, так часто происходит при рефакторинге, решать "пару проблем". Не сомневаюсь, OperationResult тут ни при чем))

Именно его и убирали, поэтому и привёл как пример из собственной практики.

ВМоисеевА почему любой модуль всегда должен что-то (код, исключение) возвращать вызывающему при ошибке?

Брошенное исключение гарантирует, что если потребитель специально его не отловит и как-то не обработает, то дальше код исполняться не будет.

Например, читаете вы файл:

var file = Some.IO.File.Read(someFilePath);

А файла нет, или прав доступа к файлу нет, или во время чтения что-то сломалось.

Что должно быть в file? Ничего не должно быть. Должно быть выброшено исключение.

ВМоисеевПусть информация об ошибке иногда останется там, внутри модуля, в объекте некоего класса. По завершению вызываюший, запросив свойство, получит ссылку на объект ошибки.

Это очень-очень, крайне плохое решение. По целому ряду причин. Вы не найдёте в популярных .NET библиотеках такого решения нигде. А если найдёте, это будет нонсенс.


ВМоисеевtry{модуль.метод();}
catch{...}
. . .
или
. . .
модуль.метод();
if(модуль.ошибка() != null) goto ?

Состояние это всегда плохо. Состояние с ошибкой последней операции -- плохо миллион-кратно. Настолько плохо, что даже не знаю, ну это как объяснять, что пить мочу -- плохо.

LRhVosttИменно его и убирали, поэтому и привёл как пример из собственной практики.
Понятно, смена поколений, пора мне в "наш уютный колумбарий"))

Поколение тут совершенно не при чём. Это не что-то модное и хипстерское. Скорее наоборот.

LRНе, наоборот - это ситуация, когда ничего еще не закодировано, а на кончиках пальцев разработчика уже есть оптимальное решение, то ли "Исключения vs коды возвратов" то ли наоборот (если что - я сейчас пьян) :))

У разработчика всё уже готово, осталось только код написать, а это фигня-вопрос ))