デバッグで意識していること

どこまでデータが来ているか確認する

データの流れを意識します。
例えば、データベースの接続より前で止まっているのか、データベースの接続完了後の値を渡すロジックで止まっているのかなどです。
どの処理で止まってしまっているのかを詳細に見ていきます。

「正常or異常」のどちらのルートを通っているか確認する

プログラムの処理で大きく分けると正常終了と異常終了があります。
どちらの処理を通ってエラーが吐き出されているのかを確認します。
ExcelのIF文にに例えると・・・

• 真の処理⇒正常終了
• 偽の処理⇒異常終了

単純なプログラムに置き換えてみる

入力データが現在通っているルートのプログラムが複雑な場合、一部を修正して単純なロジックに置き換えてみます。
そうすることでデータの流れが見えやすくなります。

違う文法に変えてみる

使用しているメソッドがサポートされていないなどでエラーが生じることもあります。
ダブルクォーテーションだとエラーになるがシングルクォーテーションだと正常終了するパターンもありました。

型を意識する

現在見ている変数の型が何になっているかに注目し、その型の渡し方などが合っているか確認します。
例えば、VBAではDATE型は#をつけたり、format()関数で定義してみたりします。
その他にも文字列型ならダブルクォーテーションが必要なケースがほとんどです。

エラーの原因だと思う部分を消してみる

エラーの部分の見当をつけて消してみます。
そこでエラーが解消すれば、今消した部分にエラーの原因があります。
プログラムの構成に必要な宣言文など一緒に消してしまわないよう注意です。

変数の中身をDISPLAYに表示してみる

変数の中身を見ることでどこまで正常にデータが流れているか確認できます。
オブジェクト型を表示させようとすると上手くいかないので注意です。

プログラムの構成に必要な宣言文を確認する

自分自身が組んだロジックだけに着目しがちですが、宣言文も確認します。
下記は一部の例です。

• COBOLならDIVISIONの終了タグが消えていないか
• SQLなら最後のカラムの後にカンマがついていないか
• ダブルクォーテーションの閉じがあるか
• 最後のセミコロンがあるか
  などです。

入力データが妥当か確認する

見当違いの入力データを入れた結果、データベースから値を取得できないケースもあります。
具体的には・・・

• データ種別が1でしか登録されていないのに、データ種別7を指定している
• 店番号123は存在しないのに、入力データとして指定している

俯瞰して見る

単体だとエラーになるが全体として見るとエラーにならないケースがあります。
上のプログラムでフィルターされてエラーの原因となるデータが落ちてこないケースなどです。
具体的には下記のようなケースです。

• プログラムBには店番号123を処理するロジックがないが、上のプログラムAで店番号123はフィルターされるため落ちてこない

この場合、プログラムBの単体テストで店番号123を入れるとエラーになりますが、気にしなくて大丈夫です。

コンパイルしたか確認する

ソースコードを修正したが、コンパイルしていなくて最新になっていないことでエラーになることもあります。

最後に（落とし穴）

完璧にプログラムを組んだと思っていても想定外の出力になることがあります。
そのような場合、下記のようなこともあります。

• ソフトウェアの設定
• 入力データがIF文やINCLUDE文でフィルターされ弾かれている
• 横にスクロールしてみると文末にゴミがある
• 決まり文句宣言文のミス
• 修正したものの最新のファイルに置き換え忘れている