Замена выброса исключений уведомлениями

Бросать Exceptionы при валидации входящих данных в .NET это последнее что бы я делал на проекте, в котором много валидации данных. Еще лет 5 назад для этого атрибуты использовались и единый подход к валидации любых полей. И писать "private void ValidateDate(..." для каждого поля в каждой модели это не многим лучше throw Exception.

Уже было, и там уже, что логично, обсудили.

Несмотря на то, что обсуждали, отпишусь в новой статье. Я проведу аналогию с Java, что возможно немногим отличается.
Этот спор возвращает нужны ли checked и non-checked exception. Повсеместно бытует мнение, что checked exception лучше не использовать, и это так, если писать библиотеку, то checked exception заметно ухудшают жизнь пользователю этой библиотеки, так как он зачастую он использует библиотеку и не ждет данных ошибок, так как они предусмотрены другими ошибками.
Однако, существует случай, когда checked exception помогают, а именно при ожидаемых ошибках, например, неправильно заполненная форма или проверка. В этом случае желательно использовать checked exception и он, конечно же, специфичен для предметной области. Например, NotAvailableSeatsException extends GenericBookingException. Это даст необходимую информацию разработчику UI, что этот exception надо словить и показать, так как он является User case exception, в отличие от NullPointerException, IllegalArgumentException и других стандартных, которые должны быть non-checked и по-хорошему не должны появляется вообще.

Что касается notification, то этот механизм имеет свои плюсы и минусы по сравнению с checked business exception. Exception уже есть и их не надо придумывать, они интегрированы с IDE, представляют изначально объектно-ориентированную модель и расширяемы, они реализуют естественный pattern fail first and further checks rely on a predictable state. Главный минус exception, что для сложных валидаций, когда надо проверить все поля сразу или структурировать или когда проверок слишком много, код написанный в таком стиле уже будет неестественным.

Не так давно столкнулся с тем, что надо было валидировать данные на уровне бизнес логики, а не на уровне представления в ASP.NET Core (3-х уровневая архитектура). После долгих раздумий решил посмотреть как же делают другие. И понравилось решение реализации валидаторов в Identity (https://github.com/aspnet/Identity), UserValidator например c IdentityResult.

Фаулер не сделал еще три простых и очевидных шага. Возможно язык, которым он оперирует, не позволил ему это сделать?

1. Вводим конструкцию, которая является коллекцией исключений и сама по себе исключением одновременно. Это и есть его объект Notification, осталось только добавить к нему реализацию Throwable
   
   
2. Позволяем нашему низкоуровневому коду (например — валидаторам конкретных полей) делать не throw new Exception, а yield new Exception. Таким образом валидатор либо молчит (всё ОК), либо генерирует серию исключений
   
   
3. Код, который на уровень выше кода из пункта 2. собирает все исключения, сгенерированные кодом из пункта 2. в контейнер-коллекцию из пункта 1. Который уже выбрасывается.

Как итог мы имеем реализацию паттерна Notification на стандартных и привычных исключениях, получая все их преимущества.

Написать что-ли Фаулеру? Мол так и так, мистер, я тут кажется придумал еще один паттерн для вас )))

Когда я задумался над вопросом (C++11): код ошибки или исключение? Решил, что нужно дать возможность пользователю API выбирать. В результате появился подход с опциональным возвращаемым кодом ошибки (реализацию подглядел в Boost.System), т.е. сигнатура метода стала выглядеть:

void someMethod(int arg0, const std::string& arg1, std::error_code &ec = throws());

а в теле:

clear_if(ec); // очистит код ошибки если не throws(). У меня размещаются в начале метода
...
throws_if<SomeExceptionClass>(ec, errcode, errcathegory); // заполнит код ошибки или выбросит SomeExceptionClass
return ...;

Реализацию можно посмотреть тут. Ограничение (меня оно не смущает) — конструктор исключения должен уметь принимать std::error_code.

А вообще идея такая: если пользователь хочет обработать какую-то ошибочную ситуацию — пусть обрабатывает (здесь и сейчас), но если забил — будет брошено исключение.