PHP学習のススメ 第4回:エラーメッセージと仲良くなろう

by 谷口 允

Posted on 07-18-2013

PHP学習のススメ

Dreamweaverl CC (2013年06月公開) 対応

この連載ではPHPそのものの紹介というよりは「PHPを学習するためには、どんな準備が必要か」という部分に焦点を当て紹介していきたいと思います。PHPの入門書籍を読み始める前に、ぜひ本連載で準備を整えてください。

Dreamweaver CC の体験版をダウンロード

PHPの学習を始めると、必ず遭遇するのが「エラー」や「バグ」という壁です。入門書に書いてあるとおりに書き写しているはずなのに、おかしなエラーメッセージが表示されてしまう。サンプルプログラムだと正しく動くのに、少しだけ変えてみるとすぐに正しく動かなくなってしまう。

こうなると、学習もスムーズに進みませんし、なにより学習意欲が失われてしまいます。プログラム上達の近道は、「エラーを出さないプログラムを作る」ことではなく、「エラーとうまく付き合う方法」と言えるかもしれません。今回は、そんなエラーとの付き合い方を紹介しましょう。

エラーメッセージを読もう

プログラム初心者にありがちなのが、エラーメッセージが表示されたとき、そのメッセージを読まずに入門書のプログラムと1文字ずつ見比べて「間違い探し」をし始めてしまうこと。この方法でエラーを取り除くのは、非常に手間がかかりますし、いつまでもエラーを回避するテクニックが身に付かないため、小さなエラーと戦い続けることになってしまいます。

まずは、エラーメッセージをしっかり読んで、恐怖心をなくしましょう。それでは、いくつか練習してみましょう。連載1回目を参考に、環境を整えてください。

まずは、次のようなプログラムを実行してみましょう。

<?php prnt(‘エラーメッセージを攻略中’); ?>

このプログラムは、あえて間違いを含んでいるため、正しく動作しません。次のようなエラーメッセージが表示されます。

Fatal error: Call to undefined function prnt() in sample01.php on line 10

このエラーメッセージを見ていきましょう。まずは、英語なので理解できない単語があれば、英和辞書などを使って調べましょう。例えば、「Fatal」は「致命的な」という意味、「undefined」は「漠然とした」とか「定義されていない」という意味で、ここでは後者の意味を用います。全体的には、次のような意味です。

致命的なエラー:sample01.phpの 10行目で、定義されていないファンクション「prnt()」が呼び出されました。

エラーメッセージを読む上で、最初のうちは、次のことに気をつけましょう。

エラーメッセージは「コンピューターの都合」で表示される

エラーメッセージは「アドバイス」ではありません。あくまでも、コンピュータがその時に起きたことを報告してくれるだけに過ぎません。上記の例では、結果的には「prnt」の綴りが間違えている(正しくは print)ことが原因ですが、そのことはエラーメッセージは教えてくれないのです。

「定義されていないファンクションが呼び出されている」という情報から、「prnt」というファンクション名の何がおかしいのかを判断し、綴り間違いに気付く必要があります。

Dreamweaverに助けてもらおう

Dreamweaverをエディターに利用していると、少し便利なことがあります。先のプログラムをDreamweaverで作ってみると、「prnt」は黒い文字で表示されています。

 Dreamweaverが認識できないキーワードは文字の色が変わりません

これを、正しく直せば下図のように緑の文字で表示されます。

 「print」と正しいスペルにすると緑の文字で表示されます

Dreamweaverは、基本的なファンクション名がDreamweaver内に記録されているため、それらのファンクション名は緑に色づけされるのです。この色を見ることで、綴り間違いを見つけやすくなります。ただし、ファンクションによっては正しく記述しても緑にならない場合もあるので、参考程度にしておきましょう。

行数は必ずしも正しくない

次に、こんなプログラムを試してみましょう。

<?php for ($i=0; $i<10; $i++): print(‘<li>’ . $i . ‘</li>’); ?>

このプログラムも正しく動作せず、次のようなエラーメッセージが表示されます。

Parse error: syntax error, unexpected end of file in sample02.php on line 16

これも訳せば、次のような日本語になります。

解析エラー: 文法エラーです。sample02.phpの 16行目でプログラムが終了するのを予期できませんでした

ここで、16行目として指定されているのはこのファイルの最後の行で、次の一文しか記述されていませんでした。

</html>

つまり、この行番号は間違いがある場所を示しているわけではないのです。

このエラーは、「for」に対応する「endfor」という記述がないことに原因があります。しかし、どこで閉じるべきかはプログラムにはわからないため、「どこで閉じるのかな?」と思いながらも全部を読み進めていき、ファイルの最後まで読んでもなお閉じられていなかったためにエラーメッセージが表示されたというわけです。

このようなエラーも、Dreamweaverを利用するとある程度防ぐことができます。下の図のように開きと閉じがあっていない場合に、行頭を赤く色づけしてくれます。こうしてあらかじめ間違いを防ぐことができます。

 Dreamweaverでは、開きと閉じがあっていない場合、行頭を赤く色づけしてくれます

最難関、エラーの表示されないバグ

エラーメッセージが表示されるような間違いは、このようにしっかりエラーメッセージの内容を理解して、プログラムを見直せば、すぐに原因は特定できます。また、プログラムを書き慣れるにつれて、徐々に間違いが減っていきます。

むしろ、プログラムを作っていて最も難しいのは、エラーが表示されないのになぜか正しく動作しないという、いわゆる「バグ(Bug)」です。バグは「小さな虫」といった意味があり、昔のコンピュータに蛾が入り込んで正しく動作しなくなったことから、プログラムが正しく動作しなくなる間違いのことを「バグ」と呼ぶようになりました。そして、このバグを取り除く作業を「Debug(デバッグ)」といいます。プログラムを作る中でも、最もやっかいで時間のかかる作業です。

それでは、次のプログラムを試してみましょう。なお、このプログラムは動作させると、ブラウザーに非常に大きな負荷がかかります。もし、ブラウザーで他のWebサイトを見ているなど、他の作業をしている場合などは、その作業を終わらせてから確認してください。

<?php $i = 0; while ($i<10): print (‘<li>バグです</li>’); $i–; endwhile; ?>

このプログラムは、実行すると図4のような画面が表示されますが、画面の読み込みが終わらず、延々とこのメッセージが表示され続けてしまいます。

 「バグです」というメッセージが延々と表示されます

では、このような自体になった場合、どのようにして原因を探ったらよいでしょうか?

exit()で強制終了させる

まず、このように終わらなくなってしまったプログラムの場合、「exit()」というファンクションを使います。これは、プログラムを強制終了するためのファンクションで、これを色々な所に埋め込んでみて、処理が終わる箇所と終わらない箇所を調べ、原因の特定を進めていきます。例えば、次の場所にexit()を入れ込んでみます。

… $i–; endwhile; exit(); ?>

これだと結果は変わらずに読み込みが終わりません。つまり、この行よりも上でバグが発生していることがわかります(この場所を①とします)。今度は、次の場所に埋め込んでみます。

<?php $i = 0; exit(); while ($i<10): …

この場合は、すぐにプログラムが終わっています。つまり、この場所と①の間でバグが発生していることがわかります。

var_dump()で変数を画面に表示する

このように動作が異常な状態になるのは、たいてい次のようなことが原因になります。

ここで参考になるのが「変数の状態」です。例えば、ここでは「$i」という変数が、プログラム内で常に変化していますが、どのように変化しているのでしょうか。それを見るためには、次のようにプログラムを変更してみます。

… $i–; var_dump($i); endwhile;

「var_dump」とは「variable dump(変数を放り出す)」というような意味のファンクションで、変数の内容を調査するときに使います。上記の結果は、下のように表示されます。var_dumpは、printファンクションと違い、その変数に「どんな種類の値が入っているか」といったことがわかる調査用のファンクションです。

 「int(-1)」というように、変数の状態も出力されています

これを見ると、$iはどんどんマイナスの値になっていることがわかります。ここまできたら、「$i–」が間違えていることに気付くでしょう。正しくは「$i++」です。

もちろん、このサンプルのような短いプログラムでは、こんなに細かく調査をしなくても、プログラムを見直せばすぐに間違いに気付くでしょう。しかし、何千行もあるようなプログラムでは、目視だけで間違いを見つけるのはかなり難しい作業となってしまうため、このような「調査テクニック」を身に付けることも必要になります。

なお、より大規模なプログラムになると、このような調査方法ではまかないきれなくなるため、「デバッガー」と呼ばれる専用のソフトウェアを用いて調査をしたり、テスト用のプログラムを利用して、自動テストをしながら開発していくという方法もあります。興味があれば「TDD(Test Driven Development)」などのキーワードで専門書を探してみてください。

プログラムを作るとき、エラーやバグに遭遇すると、非常にやる気を削がれますし、調査に時間もかかり、作る気力を失うこともあるでしょう。しかし、諦めずに原因を特定していくと、自然とバグを見つける能力が身に付き、またバグが少ないプログラムを作れるようになっていきます。

ぜひ、諦めずに頑張っていきましょう。

Topics: クリエイティブ, UI/UX & Web

Products: