記事の経緯

とあるデータベース処理の追跡を行っている際に、値を確認するためにerror_log()でbool値を扱ったところ、思いがけない形での出力が行われたため備忘録として。

実行環境

PHP 7.3.33

var_dump()とerror_log()の違い

デバッグ処理においてログを追跡するために、この二つをなんとなく使用していました。
「var_dump()はブラウザに出すとき、error_log()はブラウザに出せないとき用の関数」
という程度の認識だったのですが、bool値を扱うときは注意が必要でした。

$bool_true = true;
$bool_false = false;

// var_dumpでの出力
var_dump($bool_true);   // 出力: (bool) true
var_dump($bool_false);  // 出力: (bool) false

// error_logでの出力
error_log($bool_true);  // 出力: 1
error_log($bool_false); // 出力: ""

var_dump()はmixed型を第一引数にとります。
変数の型とその値を詳細に表示します。
error_log()はstring型を第一引数にとります。
PHPはbool値を文字列化するときのルールとして、true = 1、false = ""を返します。

そのため、本来はbool値を入れることが不適切でした。

$bool_false = false;
error_log("bool_false:" . $bool_false);

// ログファイルでの出力
[Thu Nov 21 ~~] [php7:notice] [pid xxxx] [client xxx.xxx.xx.x] bool_false:, referer: http://xxx.xxx

まるで出力されていないようにも見えるので、原因の特定に手こずってしまいます。

解決策

var_export() を使おう

error_log(var_export($bool_true, true));  // 出力: true
error_log(var_export($bool_false, true)); // 出力: false

var_export()はmixed型を第一引数にとります。
渡された変数に関する構造化された情報を返します。

error_log()はそのままだと読み取りにくいことが多いので、var_export()やprint_r()などと併用していくことを心掛けていきましょう。