Невже ловити загальні винятки насправді погано?

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

CA1031: Не вловлюйте загальні типи виключень

Я розумію обґрунтування цього правила. Але на практиці, якщо я хочу вжити однакових дій незалежно від кинутого винятку, чому я б поводився з кожним конкретно? Крім того, якщо я обробляю конкретні винятки, що робити, якщо код, який я викликаю, змінити, щоб у майбутньому викинути новий виняток? Тепер я повинен змінити свій код, щоб обробити цей новий виняток. Тоді як, якщо я просто спіймав Exceptionкод, його не потрібно змінювати.

Наприклад, якщо Foo викликає Bar, і Foo потрібно припинити обробку, незалежно від типу винятку, викинутого Bar, чи є якась перевага в тому, щоб конкретно визначити тип виключення, який я ловлю?

Можливо, кращий приклад:

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

Якщо ви не ловите загальний виняток тут, вам доведеться спіймати кожен можливий виняток. У Патріка є хороший момент, який OutOfMemoryExceptionне слід вирішувати таким чином. Що робити, якщо я хочу ігнорувати кожен виняток, але OutOfMemoryException?

Ці правила, як правило, є хорошою ідеєю, і тому їх слід дотримуватися.

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

На протилежній стороні аргументу.

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

Так, ловити загальні винятки - це погано. Виняток зазвичай означає, що програма не може робити те, про що ви її просили.

Є кілька типів винятків, з якими ви можете впоратися:

• Фатальні винятки : не вистачає пам’яті, переповнення стека тощо. Якась надприродна сила просто зіпсувала ваш Всесвіт, і процес вже вмирає. Ви не можете покращити ситуацію, тому просто відмовтеся
• Виняток викинуто через помилки в коді, який ви використовуєте : Не намагайтеся обробляти їх, а скоріше виправляйте джерело проблеми. Не використовуйте винятки для контролю потоку
• Виключні ситуації : Виправляйте виключення лише в цих випадках. Тут ми можемо включити: мережевий кабель відключений, підключення до Інтернету припинено, відсутні дозволи тощо.

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

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

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

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

Дві можливості не є взаємовиключними.

В ідеальній ситуації ви зможете знайти всі можливі типи винятків, які може створити ваш метод, обробити їх за винятком винятків, і врешті-решт додати загальне catchзастереження, щоб знайти будь-які майбутні чи невідомі винятки. Таким чином ви отримуєте найкраще з обох світів.

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

Майте на увазі, що для того, щоб знайти більш конкретні винятки, ви повинні поставити їх на перше місце.

Редагувати: З причин, викладених у коментарях, до останнього улову додано погіршення.

Я думав про те саме недавно, і мій попередній висновок полягає в тому, що просте питання виникає через те, що ієрархія .NET Exception сильно заплутана.

Візьмемо, наприклад, низький показник, ArgumentNullExceptionякий може бути розумним кандидатом на виняток, якого ви не хочете зловити, оскільки він, як правило, вказує на помилку в коді, а не на помилкову помилку виконання. Ага так. Так само NullReferenceException, за винятком випадків, що NullReferenceExceptionвипливають SystemExceptionбезпосередньо, тому немає жодного відра, в який можна помістити всі "логічні помилки", щоб ловити (або не ловити).

Тоді є головний підхід IMNSHO, який має SEHExceptionотримати (через ExternalException), SystemExceptionі, таким чином, зробити це "нормальним"SystemException Коли ви отримаєтеSEHException, ви хочете написати дамп і закінчити як можна швидше - і, починаючи з .NET 4 хоча б деякі Винятки SEH вважаються винятками з корумпованими державами, які не будуть спіймані. Хороша річ і факт, що робить цеCA1031правило ще більш марним, адже тепер ваш ледачийcatch (Exception)ніяк не зловить ці гірші типи.

Тоді, здається, що інші рамкові матеріали доволі непослідовно виводяться Exceptionбезпосередньо чи через SystemException, роблячи будь-які спроби групувати перехресні пропозиції за чимось на кшталт суперечності.

Там цей твір г Ліпперта з C#слави, звані прикрих Exception , де він виймає корисні категоризації винятків: Ви можете сказати , ви тільки хочете , щоб зловити «екзогенні» з них, за винятком ... C#мови та дизайну .NET винятки з рамки унеможливлюють "спіймання лише екзогенних" будь-яким стислим способом. _{(І, наприклад, OutOfMemoryExceptionможе дуже добре бути абсолютно нормально невиправна помилка для API , який повинен виділяти буфери, які як - то великий)}

Підсумок для мене полягає в тому, що спосіб C#роботи блоків лову і те, як розроблена ієрархія винятків Framework, правило CA1031виходить за межі абсолютно марних . Він вдає , щоб допомогти з кореневої проблемою «не проковтнула виключення» , але ковтання виключення має нульове робити з тим, що ви ловите, але з тим, що ви тоді робите:

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

Як бічна примітка, є функція C # 6 під назвою ФільтриCA1031 винятку, яка знов зробить трохи більш чинною, оскільки ви зможете належним чином, належним чином, правильно фільтрувати винятки, які ви хочете зловити, і причин для написання нефільтрованого менше catch (Exception).

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

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

Подивіться на цю відповідь ТА для більшого читання.

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

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

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

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

Як вже говорили інші, насправді складно (якщо не неможливо) уявити якусь дію, яку ви хотіли б зробити, незалежно від викинутого винятку. Лише одним із прикладів є ситуації, коли стан програми був пошкоджений і будь-яка подальша обробка може призвести до проблем (це обґрунтування Environment.FailFast).

Крім того, якщо я обробляю конкретні винятки, що робити, якщо код, який я викликаю, змінити, щоб у майбутньому викинути новий виняток? Тепер я повинен змінити свій код, щоб обробити цей новий виняток. Якщо, якщо я просто спіймав Виняток, мій код не повинен змінюватися.

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

Наприклад, якщо Foo викликає Bar, і Foo потрібно припинити обробку, незалежно від типу винятку, викинутого Bar, чи є якась перевага в тому, щоб конкретно визначити тип виключення, який я ловлю?

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

Що робити, якщо я хочу ігнорувати кожен виняток, окрім OutOfMemoryException?

ІМХО, це неправильний спосіб думати про обробку виключень. Ви повинні працювати з білими списками (вилучення типів A і B), а не з чорних списків (вибирайте всі винятки крім X).

Можливо . З кожного правила є винятки, і жодне правило не слід дотримуватися некритично. Ви, наприклад, може бути одним із випадків, коли є сенс проковтнути всі винятки. Наприклад, якщо ви хочете додати трасування до критичної виробничої системи, і ви хочете, щоб переконатися, що зміни не порушують головного завдання програми.

Однак вам слід добре подумати над можливими причинами невдачі, перш ніж ви вирішите мовчки їх ігнорувати. Наприклад, що робити, якщо причина виключення:

• помилка програмування в методі реєстрації, що призводить до того, що він завжди кидає певний виняток
• недійсний шлях до файлу реєстрації в конфігурації
• диск переповнений

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

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

Я хотів би вирішити це з логічної точки зору, а не з технічної точки зору,

Тепер я повинен змінити свій код, щоб обробити цей новий виняток.

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

Ваше питання в основному "Що робити, якщо мені байдуже, що пішло не так? Чи справді мені доведеться пережити проблеми, щоб дізнатися, що це було?"

Ось частина краси: ні, ви цього не робите.

"Отже, чи можу я просто дивитись в інший бік, і все те, що неприємне, що вискакує, автоматично підмітається під килимом і робити це з ним?"

Ні, це не так працює.

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

"Але ... але ... тоді один із тих інших винятків, про які я не дбаю, може спричинити збій мого завдання!"

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

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

Не слід ловити загальні винятки і намагатися продовжувати виконання.