【気にならないのか PHP Notice】で書きましたが、エラーの出力って無視しないことが基本的に最良かと思うわけです。
「サーバのエラーログが肥大化しているから助けて」と依頼を受けましたが、結構「あるある」的な感じだったのでメモっておきます。
ネットで検索するといろいろ便利なソースコードがあり、プログラムロジックはさておき、「コピペして動くかどうか」的にやっている人も多いかと思います（制作会社でもよくいると思います・・・）。
基本的に自分で書いていけば問題ないはずなんですが、上記のような場合、その記述が古かったりすると、PHPのバージョンが上がることによって非推奨となる関数等もあります（昔に納品した成果物なんかは、仕方がないと思いますが）。
大量エラー ereg
今回大量に出力されていたエラーは ereg() でした。
[html]
Deprecated: Function ereg() is deprecated
[/html]
原因はPHPのPOSIX 正規表現関数に掲載されている以下です。
要するに「将来PHPに実装されないから非推奨になってるよ」ということですかね。
POSIX正規表現関数 ereg
PHP 5.3.0 以降、 regex 拡張モジュールは非推奨となりました。かわりに PCRE 拡張モジュール を使うことが推奨されています。 この関数をコールすると E_DEPRECATED が発生します。 PCRE への変換についてのヘルプは 相違点の一覧 を参照ください。
「エラー出力を止める」ということであれば、方法は以下2種類ほどあるかと思います。
もっと方法はあるのかもしれませんが、単純に以下2種類しか思いつかなかったですね。
1．POSIXじゃなくPCREに変更する
時間はかかるかもしれませんが、これが一番良いんでしょうね。
やはりエラーは無視すべきじゃなく、対応すべきだろうと。
ereg であれば preg_match に置き換えてあげればOKかなぁ。
[html]
// 調整前
$str = ‘message test’;
if( ereg( ‘test’, $str ) )
// 調整後
$str = ‘message test’;
if( preg_match( ‘/test/’, $str ) )
[/html]
2．エラーレベルを変更
基本的には嫌な対処ですが、どうしてもせざるを得ない場合ですかね。
php.ini に設定する場合
[html]
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
[/html]
PHPソースファイル に設定する場合
[html]
error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED);
[/html]
httpd.conf、.htaccess に設定する場合
名前つき定数で記述はできないので、ビットマスクで記述したいのですが、エラー処理関数に以下のような記載がありました。
基本的にはこれで設定しない方が良さそうですかね。
新しい error_reporting レベル。ビットマスクまたは名前つき定数のどちらかです。将来の バージョンとの互換性を保証するために、名前つき定数の使用が 強く推奨されています。エラーレベルが追加されると、整数の幅は増加します。 そのため、以前の整数を使用するエラーレベルは常に期待通りに動作するとは 限りません。
バグの温床
やっぱりエラーはバグの温床になると思います。
エラーがまったく出力されない状態を保つのは、成果物のクオリティはもちろんですが、自分の知識を広めるためにも重要なことですよね。