Аргументи проти придушення помилок

Я знайшов подібний фрагмент коду в одному з наших проектів:

    SomeClass QueryServer(string args)
    {
        try
        {
            return SomeClass.Parse(_server.Query(args));
        }
        catch (Exception)
        {
            return null;
        }
    }

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

Коли доцільно повністю придушити всі подібні помилки?

Уявіть собі код з тисячами файлів за допомогою безлічі бібліотек. Уявіть, що всі вони закодовані так.

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

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

Навіть без надійної обробки помилок просто робити

throw new IllegalStateException("THIS SHOULD NOT HAPPENING")

або

LOGGER.error("[method name]/[arguments] should not be there")

може зекономити години.

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

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

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

Бувають випадки, коли цей шаблон корисний, але вони, як правило, використовуються тоді, коли генеровані винятки ніколи не мали бути (тобто, коли винятки використовуються для нормальної поведінки).

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

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

Це на 100% залежить від контексту. Якщо абонент такої функції має вимогу десь відображати або записувати помилки, то це, очевидно, нісенітниця. Якщо абонент ігнорував усі помилки або повідомлення про винятки, не було б багато сенсу повертати виняток або його повідомлення. Коли вимога полягає в тому, щоб змусити код припинятись лише без відображення будь-якої причини, то дзвінок

   if(QueryServer(args)==null)
      TerminateProgram();

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

  result = QueryServer(args);
  if(result!=null)
      DoSomethingMeaningful(result);
  // else ??? Mask the error and let the user run into trouble later

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

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

Дві ситуації такі:

1. Коли виняток не вважався винятковим станом

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

Можуть мати на увазі деякі необов’язкові атрибути класу.

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

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

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

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

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

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

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

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

Принципово, правильне поводження з винятком часто менше залежатиме від типу винятку, ніж місця, де воно було кинуто; якщо ресурс охороняється блокуванням читання-запису, і виняток закидається в метод, який придбав блокування для читання, належним поведінкою, як правило, є звільнення блокування, оскільки метод не міг нічого зробити з ресурсом . Якщо викид викидається під час придбання блокування для запису, замок часто повинен бути визнаний недійсним, оскільки захищений ресурс може перебувати в недійсному стані; якщо примітив блокування не має "недійсного" стану, слід додати прапор для відстеження такої недійсності. Звільнення блокування без його відключення погано, оскільки інший код може бачити об'єкт, що охороняється, у недійсному стані. Однак залишення замку звисає, чи не так та правильне рішення також. Правильним рішенням є визнання недійсним блокування таким чином, що будь-які очікувані чи майбутні спроби придбання негайно завершаться невдачею.

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

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

Тоді що вони роблять? Вони додадуть код для обробки винятку, щоб побачити, який аромат виключення вони повертають. Чудово. Але якщо обробник винятків залишений, початковий абонент більше не повертається до нуля і щось інше виходить з ладу.

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

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

• Реалізуй саме те, що мені потрібно. Може бути складним у встановлений термін.
• Змініть сторонній код. Але тоді я повинен шукати конфлікти злиття з кожним оновленням.
• Напишіть метод обгортки, щоб перетворити виняток у звичайний нульовий покажчик, булева помилка чи інше.

Наприклад, бібліотечний метод

public foo findFoo() {...} 

повертає перший foo, але якщо його немає, він викидає виняток. Але мені потрібно метод повернення першого або нуля. Тому я пишу це:

public foo myFindFoo() {
    try {
        return findFoo() 
    } 
    catch (NoFooException ex) {
        return null;
    }
}

Не акуратно. Але іноді прагматичне рішення.