Functional C#: работа с ошибками

Основное отличие типа Result от простого кода ошибки — типобезопасность. Этот тип (точнее семейство типов Result<T, E> в общем случае) сохраняет тип ошибки, что позволяет проверять валидность кода во время компиляции. С простыми кодами ошибок в виде int это не прокатит, т.к. компилятор не знает семантическую нагрузку этого int-а.

P.S. Я не претендую на знание C#, но довольно давно пишу в функциональном стиле в т.ч. на Scala, Rust, Python и немного баловался с Haskell, так что в этой области чувствую себя относительно хорошо.

При «результатах» я должен не забыть их правильно скомбинировать и пробросить наверх.

Также добавлю к ответу kstep, что правильно скомбинировать и пробросить наверх ошибку при «результатах» гораздо проще, чем при голых кодах ошибки, по крайней мере в языках типа Scala и Haskell.

Возможно вам просто привычнее стандартный подход. На деле пример в статье очень неудачный для пропаганды: он очень простой. В данном примере есть разница между тридцаткой строк почти линейного кода и десяткой строк совсем линейного кода. Поэтому безоговорочно выигрывает привычный код.
В случае, когда кода гораздо больше и необходима мультивалидация (т.е. нужно вернуть все ошибки) данный подход является более читабельным. По крайней мере, я самостоятельно пришел к такому подходу.

Да много чем плохи. Начнем с того, что исключение и ошибка — это две разные ситуации со всеми вытекающими.

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

А исключение, опять же в идеале, никто перехватывать не должен. Если оно возникло, то нужно доработать код.

Проблема сейчас в C#, такая же как и в java — отсутствие краткого синтаксиса для работы в функциональном стиле. Поэтому получается достаточно ущербный код, типа приведенного в статье. Но сама идея верна и при правильной реализации увеличивает производительность, безопасность и читаемость кода.

Я к похожим выводам в статье для scala прихожу habrahabr.ru/post/262971, где пытаюсь сравнивать исключения и монады для обработки ошибок. Правда, боюсь, рассуждения там могут быть немного сумбурными.

Для начала, нужно понимать, что есть разного рода ошибки. Есть исключительные ситуации, а есть валидация. Исключительные ситуации очень похожи на валидацию, но это как разница между интерфейсом и абстракным классом (особенно в C++) — она на уровне семантики (смысла кода). Исключительные ситуации нужны для проверки корректности работы системы. Валидация нужна для проверки корректности данных от пользователя.

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

Теперь рассмотрим другой пример. После редактирования сущности сервер должен в любом случае провалидировать корректность данных (даже если такие проверки есть на фронтовой части). При этом пользователь должен получить список всех ошибок, иначе его будет раздражать процесс работы с системой. Но вы можете бросить только одно исключение, которое увидит пользователь. Поэтому тут исключения враг. В данном случае очень хорошо работает подход с набором различных независимых валидаторов и собиранием результатов их работы. Тот же ASP.NET MVC/Web API с их ModelState.IsValid — это классический пример данного подхода. При этом при самой валидации нам не нужен стектрейс, а иногда еще и даже вреден — вы же не хотите, чтобы до юзера дошла информация о стектрейсе приложения?

Но, у подхода с набором различных независимых валидаторов есть проблемы.

Первая проблема: они независимы друг от друга.
Пример: у вас есть поля password и confirmPassword. На первое поле навешана валидация «пароль должен быть сильным», на второе поле навешана валидация «confirmPassword должен совпадать с password». Показывать обе ошибки немного странно.

Вторая проблема: они весьма криво работают как только у вас появляется мультишаговая валидация.
Пример: юзер аплоадит файл с данными. Сначала вы пытаетесь распарсить файл. В случае неуспеха вам нужно сообщить о ошибке. После парсинга файла вы уже можете валидитировать сами данные. И тут тоже нужно сообщить об ошибки. Как только таких прикольных шагов становится много — код становится очень сильно нечитаемым.

Третья проблема: они очень плохо работают когда нужно гонять запросы к бд для того, чтобы выполнить валидацию.
Пример: вы делаете штуковину, которая валидирует изменения нескольких сущностей (банальная система с выгрузкой и загрузкой данных). На одну сущность может выпасть несколько ошибок. Причем, есть некоторые ошибки, которые пожирают другие ошибки. К примеру — есть ошибка «нельзя менять данную сущность при таких-то условиях» и есть ошибки «это свойство сущности нельзя менять при таких-то условиях». Причем под каждое валидационное правило нужно подгружать разнообразные данные, что медленно. Ваш код должен показывать максимум полезных ошибок и работать минимум времени. Соберите синхрофазотрон, короче.

Прикол заключается в том, что бросить исключение это легко, привычно и требует меньше действих, поскольку интегрировано в язык. Писать набор валидаторов или Result/Validation фокусы — непривычно, да и не всегда так явно и очевидно в рамках языка. Поэтому пока что разумным подходом является смешивание подходов. Но не стоит забывать о том, что требования рано или поздно могут измениться, а времени на рефакторинг не будет.

Если рассматривать в отрыве от валидации, то исключения и ifы просто вносят дополнительную сложность в код, делая его менее линейным и более объемным. Та же Maybe монада — это всего-лишь фокус, чтобы запрятать nullcheckи и сделать код линейным и менее объемным. Никакой магии, никакого профита кроме читаемости и линейности кода. В принципе, это всего-лишь разные подходы для управления control flow. В разных ситуациях получается разные по читаемости код.