概要
error_reporting の設定を間違ってFatal Errorに気づかないこともあるので、
本当に設定には気をつけましょうねという話。
内容
アクセスなどが多いサービスになってくると、エラーレポートの中身をerror_reportingしないようにする場合も存在するが、開発時のデバッグの時には必ずE_ALLにして検証した方が良い。
理由
理由1
PHPはスクリプト言語であるため、エラーの内容がNOTICEであっても動作しないということがありうる。
理由2
同じ箇所を2箇所で利用しているような場合は、依存関係がごちゃごちゃになっていると、一つでは動作するものの、もう一つの利用箇所においては動作しないということも起こりうる。
落とし穴
- error_reporting の初期値は E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED→初期値にNoticeが含まれていない
バージョンによる error_reporting のデフォルト値
| バージョン | デフォルト値 | 意味 |
|---|---|---|
| PHP 5.3 以降 | E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED | NOTICE, DEPRECATED, STRICT以外は全てのエラーを表示 |
| PHP 5.3.0 以前 | E_ALL & ~E_NOTICE & ~E_STRICT | NOTICE, STRICT以外のエラーは全て表示 |
| PHP 4 | E_ALL & ~E_NOTICE | NOTICE以外のデータは全て表示 |
落とし穴に対する対処
開発中はできればNoticeエラーをonにする(or E_ALLのみとしておく)ことで、Noticeも含めてエラーは積極的に潰していくこと
まとめ
E_ALLで動作検証をしよう。(当たり前なのかもしれませんが、自戒を含め)
依存されている箇所は検証しようね。
参考
改めてphpのerror_reportingは心もとないなと感じた
実行時設定 - php.net
error_reporting - php.net