Политика обработки исключений в библиотеках

Question

Какова ваша политика обработки исключений при создании библиотеки .NET?В частности, какова ваша политика в отношении обработки исключений внутри библиотечных вызовов и предоставления их вызывающему коду?

Например,

• Вы бы рассматривали библиотечную функцию как любую другую, таким образом позволяяисключения, с которыми он не может справиться, как есть?
• Не могли бы вы создать собственное исключение для этой библиотеки?
• Вы бы перехватили все исключения и вместо этого выбросили исключение библиотеки?Вы бы установили исходное исключение как внутреннее исключение библиотеки?
• Как бы зависимость библиотеки от БД повлияла на вашу политику обработки исключений?

Какие рекомендации и правилаВы бы предложили для обработки исключений в библиотеке .NET?

Answer 1

• Я позволил пузырям всех исключений, которые, я думаю, пользователь сможет обработать.Это в основном то, что, я думаю, он должен увидеть (IO и т. Д.)
• Я обертываю все исключения, которые хочу отбросить, более абстрактным образом.В маппере O / R у меня было «DataAccessException», которое получало любое исключение SQL внутри, поэтому пользователю не приходилось иметь дело со своими внутренностями.Идея заключается в том, что любое приложение может захотеть узнать, что произошло исключение уровня SQL, но не может даже попытаться исправить его в любом случае (благодаря базе данных одного из многих типов и т. Д.) - так что обертка хороша.
• Я никогда не использую универсальный перехват всех вещей вне отладки.
• У меня всегда есть обработчик верхнего уровня (уровень приложения - событие необработанного исключения), чтобы попытаться показать пользователю, что произошло непредвиденное исключение, и отправить его в службу поддержки..

Пользовательские исключения - когда они имеют смысл.Это не так часто благодаря некоторым общим исключениям в каркасе.

Answer 2

Вы бы рассматривали библиотечную функцию как любую другую, таким образом позволяя всем исключения он не может справиться с потоком из это как есть?

Да, это определенно стратегия по умолчанию.

Не могли бы вы создать собственное исключение для этой библиотеки?

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

Как зависимость библиотеки от БД повлияет на вашу политику обработки исключений?

Зависимость базы данных может повлечь за собой выставление настроек, позволяющих вызывающим абонентам указывать, как библиотека обрабатывает определенные исключения (например, MaximumDeadlockRetries).

Вы бы перехватили все исключения и вместо этого выбросили исключение библиотеки? Вы бы установили оригинальное исключение как внутреннее исключение библиотеки исключение?

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

Answer 3

Библиотека, которая объединяет несколько разных классов, которые могут выдавать разные исключения, если ИМХО не позволяет исключениям изнутри просачиваться как их исходные типы. Вместо этого они должны быть заключены в специфичное для библиотеки исключение, которое как можно более четко связано с исходным типом исключения.

Например, MagicDatabaseLibrary может определять MagicDatabaseException, который, в свою очередь, имеет несколько производных исключений MagicDatabaseTimeoutException, MagicDatabaseAuthenticationException и т. Д. Если база данных SQL Server выдает исключение тайм-аута SQL Server (как бы оно ни называлось), оно должно быть включено в MagicDatabaseTimeoutException. Аналогично для любых других ожидаемых исключений, которые могут возникнуть.

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