Чому «журнал і кидок» вважається антивізером? [зачинено]

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

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

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

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

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

Log-and-throw є хорошим шаблоном, якщо суб'єкт, який ловить і повертає виняток, має підстави вважати, що він містить інформацію, яка не буде реєструватися далі в стеці викликів - принаймні, не найбільш бажаним способом. Це може статися з кількох причин:

1. Виняток може бути перехоплений та відновлений на межі рівня додатку та може містити привілейовану інформацію. Погано було б для рівня бази даних дозволити виняток, наприклад, "Спроба додати повторюваний ключ" fnord "у поле" users "", щоб досягти зовнішнього рівня програми (що, в свою чергу, може піддати його користувачеві), але це може бути корисним для внутрішніх частин бази даних викинути такий виняток та інтерфейсу програми, щоб його вловити, надійно зареєструвати та відновити дещо менш описовий виняток.
2. Виняток може становити той, який зовнішній шар, мабуть, очікував би обробляти без реєстрації, але внутрішній шар може знати щось, чого зовнішній шар не знає, що може припустити, що ведення журналу може бути корисним. Як грубий приклад, середній рівень програми може бути запрограмований на спробу підключення до одного сервера, а якщо це не працює, спробуйте інший. Затоплення журналу програми повідомленнями про "збій з'єднання", коли сервер не працює для обслуговування, може бути не корисним, тим більше, що - з точки зору програми, все працювало нормально. Може бути корисно переслати інформацію про збій з'єднання на ресурс реєстрації, пов'язаний із серверами, який потім зможе відфільтрувати журнали, щоб створити звіт про те, коли сервер піднімався і опускався, на відміну від журналу кожної спроби з'єднання .

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

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

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

Журнал і кидок ІМО є явним порушенням Принципу найменшого сюрпризу.

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