エラー抑制は悪い習慣ですか？

ここで私が確信していないコードについて質問したところ、誰かが「ところで、恐ろしいコード：エラー抑制記号（@）を多く使用しています」と答えました。

これが悪い習慣である理由はありますか？のようなもので：

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

、カスタムエラーメッセージのみを表示できます。エラーを抑制しないと、次の典型的なPHPメッセージが表示されます。

警告：mysqli :: mysqli（）：php_network_getaddresses：getaddrinfo failed：そのようなホストは不明です。中にいくつかの\ファイル\パス上のライン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エラー抑制は、後者の例と同様に不注意に行われるため、コードに対する不意の反応が生じます。

エラーの抑制は、既に知っている情報を隠すだけでなく（何かがうまくいかなかったため）悪いです。また、あなたが知らないデバッグに不可欠な情報（what、where、why）を隠すかもしれません。

この特定の例では、「データベースエラー」はあまり良いエラーメッセージではありません。DBに問題が発生しました。あまり啓発的ではありません。「警告：mysqli :: mysqli（）：php_network_getaddresses：getaddrinfo failed：そのようなホストは不明です。6行目のsome \ file \ pathに」は実際にはより良いエラーメッセージです。問題の場所と理由がわかります。エラーがすでに見つかっているため、すぐにジャンプしてデバッグを開始できます。

もちろん、ライブラリデザイナーは、多くの無関係な警告を出す傾向があることがあります。PHPには、興味のない警告をフィルタリングする方法があるかどうかを知るのに十分な知識がありません。100行のスタックトレースを読むのはあまり賢明ではないことがわかります。ただし、情報が多すぎる場合の正しい対応は、情報量をゼロに減らすことではなく、ある段階で無関係な部分を除外することです。@オペレータは、（それのモットーは、この粒度を持っていないオール・オア・ナッシング）、したがって、効果的なエラー管理に適したツールではありません。

特定のエラーが発生すること、および実際の問題を修正することは、メッセージを黙らせることよりも費用がかかること（そして、そこからの潜在的なフォールアウトに苦しむこと）を知っている場合があります。これは1回限りのスクリプトの場合もありますが、耳に指を刺して「la la la」に進むことは（潜在的な）バグに対する専門的な対応ではありません。

エラーを抑制することは問題を隠すため悪いです。それは私たちが気づいていないことも多く、金融、健康、防衛の分野で使用されるアプリケーションなど、いくつかの重要なアプリケーションで非常にコストがかかることが予想される予期しない動作を引き起こす可能性があります。

エラーメッセージは通常、コードに関する多くの情報を明らかにするため、コードに未処理の例外を含めて実際のエラーメッセージをユーザーに表示することはお勧めできません。これは悪意のあるユーザーやハッカーが操作するのに役立ちます。システム。

したがって、エラーを異なるレベルで処理することをお勧めします。たとえば、最高レベルでは、実際のエラーをログに記録し、ユーザーに簡単でわかりやすいメッセージを表示するだけでエラーを処理できます。

はい、エラー抑制演算子は一般に悪い考えです。

構成でエラー報告を管理する必要があります（php.ini）。そのため、環境ごとに異なる設定を選択できます（たとえば、開発中に警告を残し、本番ではそれらを非表示にします）。

使用@する意味がある唯一の状況は、他の開発者向けのライブラリを開発する場合です。警告を生成する何かを自発的に選択し、ライブラリのユーザーに依存していない警告でユーザーを困らせたくない@場合は、解決策になる可能性があります。

他の用途は考えられません。