Бизнес-компонент с множеством разных типов ошибок

Question

Это всего лишь вопрос общего дизайна. Если вы разрабатываете бизнес-компонент или сервис (например, объект / сервис, который предоставляет относительно простой интерфейс для обработки транзакций выставления счетов), какие есть хорошие способы обработки ошибок, связанных с бизнесом?

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

Это кажется трудной задачей, потому что становится неудобно иметь дело с проверками бизнес-правил с использованием исключений, и я читал в нескольких местах, чтобы избежать использования исключений для управления «неисключительными» или бизнес-логическими потоками. Я чувствую, что термин «исключительный» часто является дискуссионным, и он становится неуместным, пытаясь сохранить разные случаи, определенные как «исключительные» и «не исключительные». (например, если ваша бизнес-логика проверяет ограничения расходов, возрастные ограничения и т. д.). В то же время использование схемы кодов ошибок также неудобно, поскольку вызывающий абонент может игнорировать коды ошибок.

Любые советы или рекомендации будут оценены!

Answer 1

Нет абсолютно ничего, что могло бы помешать вам делать исключения как из правил, так и из правил. Я бы использовал исключения в двух случаях:

1. Нарушение предусловия . Если спецификация вашей функции гласит: «потраченная сумма не должна превышать лимит для этого типа учетной записи», и пользователь, зная это , в любом случае указывает больший лимит, кидает исключение прямо в него!

2. Нарушение постусловия . Если все предварительные условия выполнены, но из-за непредвиденного отказа (например, соединение с базой данных или завершение транзакции нарушает антимонопольное законодательство), вы не можете предоставить правильный результат, не предоставляйте его. Брось исключение.

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

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

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

Answer 2

Ошибки, связанные с бизнесом, не должны быть исключениями. Исключения есть, если в программе есть событие, которое программа не предназначена для обработки или полностью непредвиденная. С этой целью, если вы ожидаете большое количество различных исключений, непременно используйте некоторую полезную схему нумерации. Здесь я бы порекомендовал гид по причине повторного использования компонента. Каждый компонент должен предоставлять некоторый интерфейс для запроса списка возможных номеров исключений (затем его можно добавить в хранилище данных для документации). Кроме того, при повторном использовании компонентов коды ошибок не будут конфликтовать.

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

Answer 3

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

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

См http://msdn.microsoft.com/en-us/library/ms229030.aspx для отличного обсуждения этого. (Это также в книге Руководство по разработке фреймворка .)

Answer 4

Я бы пошел на схему кода ошибки, потому что вы сказали «много разных вещей, которые могут пойти не так». Возможно, вы захотите иметь схему, которая возвращает объекты List of Error, где Error будет инкапсулировать код, объяснение, исходные данные и т. Д.

Исключение может сказать только одну вещь, которая неправильна, и она должна иметь "исключительную" природу, а не обычную проблему.

Или, возможно, гибрид, в котором вы генерируете исключение, в котором объекты List of Error являются частным элементом данных, и метод доступа, который позволяет перебирать ошибки.