Чому ми не кидаємо ці винятки?

Я натрапив на цю сторінку MSDN, де зазначено:

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

На жаль, пояснити, чому це не турбує, це не турбує. Я можу здогадатися про причини, але сподіваюся, що хтось більш авторитетний з цього приводу може запропонувати своє розуміння.

Перші два мають певний сенс, але останні два здаються такими, які ви хотіли б використати (а насправді я маю).

Далі, це єдині винятки, яких слід уникати? Якщо є інші, що вони такі і чому їх теж слід уникати?

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

Ця ж причина стосується і SystemException. Якщо ви подивитесь на перелік похідних типів, ви можете побачити величезну кількість інших винятків з дуже різною семантикою.

NullReferenceExceptionі IndexOutOfRangeExceptionмають різний вид. Зараз це дуже конкретні винятки, тому кидати їх можна було б чудово. Однак ви все одно не хочете їх кидати, оскільки вони зазвичай означають, що в вашій логіці є деякі фактичні помилки. Наприклад, виключення з нульовою посиланням означає, що ви намагаєтеся отримати доступ до члена об'єкта, який є null. Якщо така можливість є у вашому коді, то завжди слід чітко перевірити nullі замість цього викинути корисніше виключення (наприклад ArgumentNullException). Аналогічно, IndexOutOfRangeExceptions трапляються, коли ви отримуєте доступ до недійсного індексу (для масивів - не списків). Ви завжди повинні переконатися, що ви цього не робите в першу чергу і спочатку перевірте межі, наприклад, масив.

Є кілька інших винятків , наприклад , ті два, наприклад , InvalidCastExceptionабо DivideByZeroException, які викидаються для конкретних помилок в коді і , як правило , означають , що ви робите що - то неправильно або ви не перевіряючи для деяких неприпустимих значень першого. Закидаючи їх свідомо з вашого коду, ви просто ускладнюєте код, який викликає, щоб визначити, чи були вони кинуті через якусь несправність у коді, чи просто тому, що ви вирішили використати їх для чогось у вашій реалізації.

Звичайно, є деякі винятки (га) цих правил. Якщо ви будуєте щось, що може спричинити виняток, який точно відповідає існуючому, тоді сміливо використовуйте це, особливо якщо ви намагаєтесь відповідати деякій вбудованій поведінці. Просто переконайтеся, що тоді ви вибрали дуже конкретний тип виключення.

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

Я підозрюю, що намір із останніми 2 - запобігти плутанині з вбудованими винятками, які мають очікуване значення. Однак я вважаю, що якщо ви зберігаєте точний намір виключення : це правильний варіант throw. Наприклад, якщо ви пишете власну колекцію, використовувати її цілком розумно IndexOutOfRangeException- зрозуміліше і конкретніше, IMO, ніж ArgumentOutOfRangeException. І хоча, List<T>можливо, вибирають останнє, у BCL (не враховуючи масиви), що підпадають під замовлення, є щонайменше 41 місце (з урахуванням рефлектора) IndexOutOfRangeException- жодне з яких не є "низьким рівнем", щоб заслужити спеціальне звільнення. Так, так, я думаю, ви можете справедливо стверджувати, що ця настанова нерозумна. Так само,NullReferenceException якась корисна в методах розширення - якщо ви хочете зберегти семантичне, що:

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

кидає a NullReferenceExceptionколи objє null.

Як ви зазначаєте, у статті Створення та викидання винятків (Посібник з програмування C #) під темою Що слід уникати, коли викидаєте винятки , Microsoft дійсно перераховуєSystem.IndexOutOfRangeException як тип виключення, який не слід навмисно викидати з вашого власного вихідного коду.

На відміну від цього, у статті, що стосується статті (C # Reference) , 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я не бачу причини забороняти це у всіх випадках.

EDIT: також зі сторінки MSDN:

Винятки не слід використовувати для зміни потоку програми як частини звичайного виконання. Винятки слід використовувати лише для повідомлення та обробки умов помилки.

Не є найкращою практикою також передозування застережень щодо вилову з індивідуальною логікою для різних типів виключень.