2

私はエラーを無視するよりもよく知っています、約束します。XML-Sitemaps ジェネレーターを実行すると、CodeIgniter を喜ばせる有効なセッション情報がない URL にヒットします。その結果、クロールされたすべてのページに対して 1 つの E_NOTICE とログ (および電子メール通知) が作成され、気が狂いそうになります。何も壊れず、人やロボットに害はありません。影響を受けるのは私の正気だけです。

何人かの人々が CodeIgniter の unserialize() の失敗を修正しました:

私はそれぞれの前提で実行しましたが、それでも何百もの次の通知を受け取ります。

NOTICE: unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 98 of 128 bytes

これにより、非常に単純な質問で振り出しに戻ることができます。CIのSession.phpの問題のある行724は次のとおりです。

$data = @unserialize(strip_slashes($data));

私は抑圧的な「@」を追加しませんでした – それはすでにそこにありました. それは、スローされた場合に E_NOTICE メッセージを具体的に抑制するということではないでしょうか? そうでない場合、その行は、髪の毛をすべて引き裂きたくなるようなこれらすべての通知をどのように生成できるのでしょうか?

4

1 に答える 1

5

カスタム エラー ハンドラーを設定すると、PHP のエラー処理がバイパスされ、明らかに PHP のエラー抑制がバイパスされます。

コールバック関数が FALSE を返さない限り、error_types で指定されたエラー タイプに対して標準の PHP エラー ハンドラが完全にバイパスされることを覚えておくことが重要です。error_reporting() の設定は効果がなく、エラー ハンドラが呼び出されますが、error_reporting の現在の値を読み取って適切に処理することはできます。特に注意すべきは、エラーの原因となったステートメントの前に @ error-control 演算子が追加された場合、この値は 0 になるということです。

<?php
set_error_handler(function ($errno, $errstr) {
    echo $errstr;
}, E_ALL);
@unserialize("foo"); // Still shows $errstr!

これは PHP に引き継がれ、おそらくエラー抑制設定を無視します。おそらく、CodeIgniter は独自のエラー ハンドラを使用しており (これはあると思います)、エラー抑制レベルに関係なくエラーを吐き出しています。

ただし、PHP は、エラー報告レベルをチェックしてゼロに等しいかどうかを確認すると、エラーが抑制されているかどうかがわかることを暗示しているようです。したがって、理論的には、CodeIgniter エラー ハンドラを編集して、if (error_reporting()) { /* show error */ }.

于 2012-08-31T16:42:22.130 に答える