Политика обработки исключений в библиотеках
При создании библиотеки.NET, какова политика обработки исключений? В определенном, какова Ваша политика об обработке исключений в вызовах библиотеки и представления их к коду вызова?
Например,
- Вы рассматривали бы библиотечную функцию как кто-либо другой, таким образом позволяя всем исключениям, которые она разве обрабатывает, не может вытечь из него как есть?
- Вы создали бы пользовательское исключение для той библиотеки?
- Вы поймали бы все исключения и выдали бы исключение библиотеки вместо этого? Вы установили бы исходное исключение как внутреннюю исключительную ситуацию исключения библиотеки?
- Как был бы зависимость библиотеки от DB влиять на Вашу политику обработки исключений?
Какие инструкции и правила Вы предложили бы для обработки исключений в библиотеке.NET?
2 ответа
Будете ли вы относиться к библиотечной функции как к любой другой, таким образом позволяя всем исключениям, которые она не может обработать, вытекать из как есть?
Да, это определенно стратегия по умолчанию.
Создадите ли вы собственное исключение для этой библиотеки?
Да, если вызывающие могут что-то сделать с ситуацией и для этого они должны быть в состоянии отличить исключение от других исключений. Но это бывает довольно редко.
Как зависимость библиотеки от БД повлияет на вашу политику обработки исключений?
Зависимость от БД может повлечь за собой раскрытие параметров, позволяющих вызывающим пользователям указывать, как библиотека обрабатывает определенные исключения (например, MaximumDeadlockRetries).
Будете ли вы перехватывать все исключения и вместо них бросать исключение библиотеки? Установите ли вы исходное исключение в качестве внутреннего исключения библиотеки исключение?
Нет, не все исключения. Для определенных исключений это вполне возможно, хотя единственный случай, который я могу представить, когда я мог бы захотеть это сделать, это когда моя библиотека уже пыталась обработать исключение (как в сценарии с базой данных выше) и потерпела неудачу.
- Я разрешаю все исключения, с которыми, как мне кажется, пользователь может справиться. Это в основном те вещи, которые, по моему мнению, он должен ожидать увидеть (IO и т.д.)
- Я оборачиваю все исключения, которые я хочу отбросить, в более абстрактную форму. В O/R mapper у меня был "DataAccessException", который получал любое исключение SQL внутри - так что пользователю не приходилось иметь дело с их внутренними особенностями. Идея здесь в том, что любое приложение может захотеть узнать, что произошло исключение на уровне SQL, но не может даже потрудиться попытаться исправить его в любом случае (благодаря тому, что база данных является одной из многих типов и т.д.) - так что обертка хороша.
- Я никогда не использую общие catch all вне отладки.
- У меня всегда есть обработчик верхнего уровня (уровень appdomain - событие не обработанного исключения), чтобы попытаться показать пользователю, что произошло неожиданное исключение, и отправить его в службу поддержки.
Пользовательские исключения - когда они имеют смысл. Это случается не так часто благодаря некоторым общим исключениям во фреймворке.