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

Я наткнулся на эту страницу MSDN, в которой говорится:

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

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

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

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

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

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

NullReferenceExceptionи IndexOutOfRangeExceptionбывают другого рода. Это очень специфические исключения, поэтому их можно выбросить . Однако вы все равно не захотите их бросать, поскольку они обычно означают, что в вашей логике есть некоторые реальные ошибки. Например, исключение нулевой ссылки означает, что вы пытаетесь получить доступ к члену объекта, который является null. Если это возможно в вашем коде, вам всегда следует явно проверять nullи генерировать более полезное исключение (например ArgumentNullException). Так же,IndexOutOfRangeException s возникают, когда вы обращаетесь к недопустимому индексу (для массивов, а не списков). Вы всегда должны сначала убедиться, что вы этого не делаете, и сначала проверять границы, например, массива.

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

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

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

Я подозреваю, что намерение последних двух состоит в том, чтобы предотвратить путаницу со встроенными исключениями, которые имеют ожидаемое значение. Однако я считаю, что если вы сохраняете точное намерение исключения : оно правильное throw. Например, если вы пишете собственную коллекцию, кажется вполне разумным использовать IndexOutOfRangeException- более ясный и конкретный, IMO, чем ArgumentOutOfRangeException. И хотя вы List<T>можете выбрать последнее, в BCL есть не менее 41 места (благодаря отражателю) (не считая массивов), которые создают индивидуальные настройки IndexOutOfRangeException- ни одно из них не является «низким уровнем», чтобы заслуживать особого исключения. Так что да, я думаю, вы можете справедливо возразить, что это правило глупо. Точно так же,NullReferenceException полезен в методах расширения - если вы хотите сохранить семантику, которая:

obj.SomeMethod(); // this is actually an extension method

выкидывает NullReferenceExceptionкогда objесть null.

Как вы указываете, в статье Создание и выброс исключений (Руководство по программированию на C #) в разделе « Чего следует избегать приSystem.IndexOutOfRangeException создании исключений» Microsoft действительно указывает тип исключения, который не следует намеренно создавать из вашего собственного исходного кода.

Однако в отличие от статьи throw (Справочник по C #) Microsoft, похоже, нарушает свои собственные правила. Вот метод, который Microsoft включила в свой пример:

static int GetNumber(int index)
{
    int[] nums = { 300, 600, 900 };
    if (index > nums.Length)
    {
        throw new IndexOutOfRangeException();
    }
    return nums[index];
}

Таким образом, сама Microsoft не является последовательной, поскольку IndexOutOfRangeExceptionв своей документации для throw!

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

Когда я прочитал ваш вопрос, я спросил себя, при каких условиях нужно выбросить типы исключений NullReferenceException, InvalidCastExceptionили ArgumentOutOfRangeException.

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

PS: С 2003 года я занимаюсь разработкой собственных исключений, поэтому могу выбросить их как захочу. Я думаю, что это считается лучшей практикой.

Отложив обсуждение NullReferenceExceptionи IndexOutOfBoundsExceptionотложим в сторону:

Насчет ловли и бросания System.Exception. Я часто создавал исключения этого типа в своем коде, и меня это никогда не подводило. Точно так же очень часто я ловлю неспецифический Exceptionтип, и у меня это тоже неплохо сработало. Итак, почему это так?

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

Итак, что касается метания, Exceptionя не вижу причин запрещать это во всех случаях.

РЕДАКТИРОВАТЬ: также со страницы MSDN:

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

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