Есть ли в C # встроенные исключения, которые я не должен использовать? - PullRequest
11 голосов
/ 18 апреля 2009

Существуют ли какие-либо исключения, определенные в .NET Framework, которые я не должен добавлять в свой собственный код, или это плохая практика? Должен ли я написать свой собственный?

Ответы [ 6 ]

22 голосов
/ 18 апреля 2009

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

  • StackOverflowException
  • NullReferenceException
  • AccessViolationException
  • и т.д ...

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

Причина в том, что при активно сгенерированном исключении обычно представляет известное состояние в API. Если я вызываю API, и он выдает ArgumentException, у меня есть разумное ожидание, что данный объект находится в хорошем состоянии. Это признало потенциально плохую ситуацию и активно объяснило это. С другой стороны, если он генерирует исключение NullRefrenceException, это указывает на то, что API обнаружил неизвестную ошибку и теперь находится в ненадежном состоянии.

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

РЕДАКТИРОВАТЬ Ответ на комментарий Михаила

Вы также не должны напрямую генерировать Exception, ApplicationException или SystemException. Эти типы исключений слишком общие, чтобы предоставлять значимую информацию к коду, который вызывает ваш API. Правда, вы можете поместить очень описательное сообщение в параметр сообщения. Но поймать исключение, основанное на сообщении, нелегко и просто. Гораздо лучше ловить его по типу.

Правило FxCop на эту тему: http://msdn.microsoft.com/en-us/library/ms182338(VS.80).aspx

9 голосов
/ 18 апреля 2009

Большинство исключительных классов в платформе не предназначены для повторного использования, поскольку они обычно создаются для сообщения об ошибке, специфичной для платформы. Подобно , упомянутым @ JaredPar , они используются платформой для указания определенных состояний в платформе.

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

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

3 голосов
/ 10 февраля 2010

@ Майкл В действительности существует одна ситуация, в которой рекомендуется генерировать исключение NullReferenceException: если первый параметр (параметр "this") метода расширения равен нулю. Это необходимо сделать для того, чтобы нулевые переменные вели себя как положено.

2 голосов
/ 18 апреля 2009

Microsoft однажды сказала программистам не наследовать напрямую от Exception, а вместо этого использовать ApplicationException в качестве базового класса. Не уверен, правда ли, что это мнение все еще верно ...

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

Марк

0 голосов
/ 19 апреля 2009

Онлайн Руководство по проектированию исключений содержит принципиальный совет (см. Конкретно эту страницу).

В книге "Руководство по разработке структуры: условные обозначения, идиомы и шаблоны для многократно используемых библиотек .NET, 2-е издание" содержится более подробная информация и более подробное обсуждение этой темы.

0 голосов
/ 18 апреля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...