Чи придушення помилок є поганою практикою?

На запитання ТА, який я запитав тут про якийсь код, про який я не був упевнений, хтось відповів "BTW, жахливий код там: він дуже часто використовує символ придушення помилки (@)".

Чи є причина, чому це погана практика? З такими речами, як:

$db=@new mysqli($db_info) or die('Database error');

, це дозволяє мені відображати лише власне повідомлення про помилку. Без придушення помилок, воно все одно відображатиме типове повідомлення PHP:

Попередження : mysqli :: mysqli (): php_network_getaddresses: getaddrinfo не вдалося: Такого хоста не відомо. у деяких \ file \ шлях у рядку 6

а також "Помилка бази даних".

Чи придушення помилок завжди погано, і якщо так, то конкретно про вищезазначене погано?

Оновлення: фактичний код, який я використовую:

or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' : ''))

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

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

Можливо, буде простіше вважати еквівалент, скажімо, на Java. Придушення помилки за допомогою @аналогічно проковтненню винятку. Наступний код, подібний до вашого, є розумним:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(Ну, на Java, ви б не хотіли, щоб двигун сервлетів помер, але ви отримаєте ідею.)

Однак це не прийнятно:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

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

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

У цьому конкретному прикладі " Помилка бази даних " не є дуже хорошим повідомленням про помилку. Щось пішло не так із БД. Не дуже просвітницька. « Попередження: MySQLi :: MySQLi (): php_network_getaddresses: getaddrinfo не вдалося: Немає такого хоста невідомо. у деяких \ file \ шлях у рядку 6 ”насправді є кращим повідомленням про помилку. Це дає вам місце та причину проблеми. Ви можете заскочити прямо і почати налагодження, оскільки помилка вже знайдена.

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

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

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

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

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

Так, оператор придушення помилок, як правило, погана ідея.

Вам слід керувати повідомленнями про помилки в конфігурації ( php.ini). Таким чином, ви можете вибрати інше налаштування для кожного середовища (наприклад, залиште попередження щодо розвитку та заховайте їх у виробництві).

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

Я не можу придумати жодного іншого використання.