Какие факторы следует учитывать при написании пользовательского класса исключений?

Question

Когда пользовательские классы исключений наиболее ценны?
Есть ли случаи, когда их следует или не следует использовать? Каковы преимущества?

Похожие вопросы:

1. Особенности исполнения при создании исключений
2. Вы пишете исключения для конкретных проблем или общие исключения?

Answer 1

Вопросы для себя:

1. Кто будет ловить это? Если никого нет, то вам не нужно особенное исключение.
2. Куда ты его бросишь? Достаточно ли достаточно контекста, или вам нужно будет несколько раз перехватывать и перебрасывать, прежде чем исключение будет полезно для финального ловца?
3. Почему ты это бросаешь? Потому что вы поймали исключение и нужно приложить дополнительную информацию? Потому что вы столкнулись с неисправимой ошибкой в ​​некоторых данных, и вам необходимо сообщить подробности клиентскому коду? Потому что тебе нравятся throw вещи?
4. Что является исключением? Не то, что вызвало это, но что это с точки зрения ловца ? Что-то они могут исправить и повторить? Что-то, что они должны никогда повторить? О чем они должны уведомлять пользователя? Что-то, к чему они должны прикрепить контекстную информацию, а затем повторно выбросить? Что определяет информацию, которую вам нужно передать, если таковая имеется ...

Заповедь:

1. Не тратьте время на пользовательские исключения, которые никогда не будут обнаружены.
2. Не «дублируйте» исключения: у каждого пользовательского типа исключения должен быть четко определенный случай, когда его можно и нужно отлавливать; исключения, которые не совпадают, должны быть разбиты на их собственные пользовательские типы (вместо того, чтобы, скажем, заставлять перехватчик создавать условную логику в одном предложении catch()).
3. Если у вас нет веской причины не делать этого, всегда разрешайте прикреплять внутреннее исключение / данные из ранее обнаруженного исключения. Потеря контекста редко помогает.

Answer 2

Моей основной причиной использования пользовательских исключений будет инкапсуляция с несколькими провайдерами: наличие утечки SqlException из уровня SqlDataAccess и исключение SocketException из уровня NetworkDataAccess делает вызывающий код зависимым от особенностей вашего реализация. Лучше обернуть их в DataAccessException или что-то еще.

Answer 3

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

Answer 4

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

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

Если вы используете .NET, посмотрите Разработка пользовательских исключений . Интересно, что документация изменила свою рекомендацию об использовании ApplicationException:

Если вы разрабатываете приложение который должен создать свой собственный исключения, вам рекомендуется вывести пользовательские исключения из исключения учебный класс. Первоначально считалось, что пользовательские исключения должны происходить из класс ApplicationException; Однако на практике это не было найдено, чтобы добавить значительную ценность. За больше информации, см. Best Practices для обработки исключений.

Answer 5

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

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

В C ++ и, возможно, в некоторых других языках вы также можете вводить исключение. Это позволило бы различать типы и, возможно, в будущем преобразовать их в пользовательский класс.

Answer 6

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

Answer 7

Я думаю, что простой ответ: «Создайте пользовательское исключение, если ни одно из существующих исключений не выражает исключительную ситуацию».

У меня также есть второе правило, которое я применяю: «Создавайте пользовательское исключение, только если вы ожидаете, что разработчик сможет обработать это исключение». Нет смысла создавать новое исключение, если вы не считаете исключение восстанавливаемым условием. Это более эффективно, чтобы бросить InvalidOperationException в этом контексте.

РЕДАКТИРОВАТЬ: закончилась запись в блоге на эту тему: http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx