MethodA викликає MethodB, який, в свою чергу, викликає MethodC.

У методіB або MethodC немає обробляння винятків. Але в MethodA є обробка винятків.

У MethodC відбувається виняток.

Тепер цей виняток перекидається до MethodA, який обробляє його належним чином.

Що з цим не так?

На мою думку, в якийсь момент абонент виконує MethodB або MethodC, і коли в цих методах трапляються винятки, що буде отримано від обробки виключень усередині цих методів, що по суті є просто блоком спробувати / зловити / нарешті замість просто дозволити вони пузиряться до мозолі?

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

Я розумію це, коли потрібно звільнити ресурси. Це зовсім інша справа.

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

Єдині причини, чому метод повинен мати механізм уловлювання та повторного відкидання:

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

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

Що з цим не так?

Абсолютно нічого.

Тепер цей виняток перекидається до MethodA, який обробляє його належним чином.

"належним чином обробляє це" є важливою частиною. У цьому суть структурованої обробки виключень.

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

. . . чому б не зловити виняток далі по ланцюжку, а не блокувати спробу / ловити всю дорогу вниз.

Саме це і слід робити. Якщо ви читаєте код, який має обробника / повторного викупування "до кінця вниз", ви [ймовірно] читаєте досить поганий код.

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

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

Ви повинні змінити значення "Бібліотеки" та "Програми".

Бібліотеки можуть вільно кидати неприховані винятки

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

У вашій бібліотеці найчастіше не знайдеться способу розумного поводження з ними . Єдине розумне рішення - кинути відповідний Виняток і дозволити розробнику Додатку займатися цим.

Програми завжди повинні бути винятками

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

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

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

Що не так з візерунком, який ви описуєте, це те, що метод A не зможе розрізнити три сценарії:

1. Спосіб B не вдався очікуваним чином.

2. Метод C не вдався таким чином, як не передбачалося методом B, але поки метод B виконував операцію, від якої можна було б безпечно відмовитися.

3. Метод C не вдався таким чином, як це не передбачалося методом B, але поки метод B виконував операцію, яка розміщувала речі у передбачуваному тимчасовому непорядному стані, який B не зміг очистити через збій C.

Єдиний спосіб методу A зможе розрізнити ці сценарії, якщо виняток, викинутий з B, містить інформацію, достатню для цієї мети, або якщо розмотування стека для методу B призводить до того, що об'єкт залишається в явно недійсному стані. На жаль, більшість рамок винятків роблять обидва зразки незручними, змушуючи програмістів приймати дизайнерські рішення "менше зла".