Какие встроенные исключения .NET я могу выбросить из своего приложения?

Question

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

Answer 1

См. Создание и создание исключений .

При выдаче встроенных исключений написано:

Не создавайте намеренно исключение System.Exception, System.SystemException, System.NullReferenceException или System.IndexOutOfRangeException из собственного исходного кода.

и

Не выбрасывайте общие исключения

Если вы генерируете общий тип исключения, например Exception или SystemException, в библиотеке или инфраструктуре, это заставляет потребителей перехватывать все исключения, включая неизвестные исключения, которые они не знают, как обрабатывать.

Вместо этого либо добавьте более производный тип, который уже существует в платформе, либо создайте свой собственный тип, производный от Exception. "

Эта запись в блоге также содержит несколько полезных рекомендаций.

Кроме того, анализ кода FxCop определяет список «не вызывать исключения» как , описанное здесь . Он рекомендует:

Следующие типы исключений являются слишком общими для предоставления пользователю достаточной информации:

• System.Exception
• System.ApplicationException
• System.SystemException

Следующие типы исключений зарезервированы и должны создаваться только общеязыковой средой исполнения:

• System.ExecutionEngineException
• System.IndexOutOfRangeException
• System.NullReferenceException
• System.OutOfMemoryException

Таким образом, теоретически вы можете поднять любой другой тип исключений фреймворка, при условии, что вы четко понимаете цель исключения, как описано Microsoft (см. Документацию MSDN).

Обратите внимание, что это «руководящие принципы», и, как говорили некоторые другие, существует спор вокруг System.IndexOutOfRangeException (т.е. многие разработчики выдают это исключение).

Answer 2

По предмету System.Exception и System.ApplicationException: последний должен был использоваться в качестве базового класса всех пользовательских исключений. Однако, это не было выполнено последовательно с самого начала. Следовательно, есть противоречие, должен ли этот класс использоваться вообще вместо использования System.Exception как базовый класс для всех исключений.

Какой бы путь вы ни решили, никогда не сгенерирует экземпляр этих двух классов напрямую. Жаль, что они не abstact. Для чего бы это ни стоило, всегда старайтесь использовать максимально возможное исключение. Если нет никого, чтобы удовлетворить ваши требования, не стесняйтесь создавать свои собственные. Однако в этом случае убедитесь, что ваше исключение имеет преимущество перед существующими исключениями. В частности, он должен прекрасно передавать его значение и предоставлять всю информацию, необходимую для осмысленного урегулирования ситуации.

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

Answer 3

Я регулярно пользуюсь ArgumentException (и его «друзьями»).

NotSupportedException и NotImplementedException также распространены.

Answer 4

Мой совет будет сосредоточиться на двух вещах:

1. Сценарии
2. Пользовательские ожидания

Другими словами, я бы сел и определил:

1. При каких сценариях вы хотите генерировать исключения.
2. В этих случаях, что ожидают пользователи вашего API

Ответ на # 1, конечно, зависит от приложения. Ответ на вопрос №2 - «что когда-либо похожий код, с которым они уже знакомы, делает».

Поведение, которое получается из этого:

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

   2. Для новых сценариев, которые не существуют в рамках, вы должны пойти дальше и придумать ваши собственные классы исключений. Я бы сказал, что вы должны предпочесть Exception в качестве своей базы класс, если они не являются каким-то другим базовым исключением, предоставляющим необходимые вам услуги Вообще говоря, я не думаю, что что-то вроде «ApplicationException» поможет вам много. Когда вы начинаете определять свои собственные исключения, есть несколько вещей, которые вы должны Имейте в виду, хотя:

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

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

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

Answer 5

Вы можете создавать и бросать практически любые из них, но, как правило, не следует. Например, различные исключения проверки аргументов (ArgumentException, ArgumentNullException, ArgumentOutOfRangeException и т. Д.) Подходят для использования в коде приложения, но AccessViolationException - нет. ApplicationException предоставляется в качестве подходящего базового класса для любых пользовательских классов исключений, которые могут вам потребоваться.

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