Из каких классов я должен получить свои собственные DataAccessLayerException и DuplicateEntryException?

Question

Я хочу добавить классы DataAccessLayerException и DuplicateEntryException. Но я сомневаюсь, из каких классов мне следует учиться? Например, DataAccessLayerException (будет использоваться в качестве оболочки для исключений, выбрасываемых из уровня доступа к данным) может быть получен из Exception или DbException. Но я боюсь, что DbException должен быть базовым классом только для исключений провайдера, таких как OracleException или SqliteException и так далее. Я не знаю. И DuplicateEntryException (да, я ненавижу, что это исключение не реализовано поставщиками БД, поэтому я создам его сам) может быть получено из Exception или DbException или даже из DataAccessLayerException.

Что ты думаешь? Также приведите аргументы, почему вы так думаете.

Пожалуйста, только опытные разработчики / архитекторы.

Заранее спасибо.

Answer 1

Если это большой проект, я склонен иметь базовый класс исключений, который получается из System.Exception для всех исключений, специфичных для домена. Таким образом, если имя продукта - «Foo», то все исключения происходят из «FooException».

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

• Если вы когда-нибудь захотите объединить проекты или написать гибридные приложения, наличие этого класса в корне иерархии ясно говорит вам, в какой подсистеме есть правило или предположение, которое было нарушено. Облегчает исследование сообщения об ошибке в какой-то большой оркестровке.
• Это совершенно недвусмысленный стандарт, и разработчикам никогда не придется беспокоиться о таких вещах, как наследование от Exception или DbException.
• Упрощает добавление глобальной информации о проекте в дерево исключений, если вам когда-либо понадобится (например, веб-приложение / служба может захотеть включить информацию о текущем контексте безопасности или узле сервера, на котором произошло исключение) на). Не то чтобы вам это всегда было нужно или нужно, но бывают случаи, когда вы можете.

Если у вас есть несколько крупных подпроектов (скажем, Foo.Core для модели домена, Foo.Data для уровня данных, Foo.Services для бизнес-логики и Foo.UI для модели представления), тогда я мог бы также создайте корневое исключение для каждого из FooException. В этом конкретном случае это будет FooDataException, и каждое исключение, происходящее в DAL (например, DuplicateEntryException), происходит из этого. У вас также были бы ваши FooServiceException и FooUIException и все остальное.

Хотя это просто мнение. Я не думаю, что есть правильный или неправильный ответ.

Редактировать: За исключением ApplicationException, который является неправильным ответом!

Answer 2

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

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

P.S. Я понятия не имею, квалифицируюсь ли я как опытный разработчик / архитектор, но у меня есть мнения.