http://dixq.net/forum/viewtopic.php?f=3&t=13703
この記事を読んで「そういえばデバッグ無しとかリリースビルドであんまり実行してないな」と思い立ち、実行。
見事になんか落ちた。
確認してみたところ、スクリプトファイルの不正な記述で落ちてたんですが、引数の数が不正だった場合に例外をあげる処理が抜けてる部分がいくつかあるのを発見。
いろんな意味で危なかった。
人間(というか僕)が書くコードにあまり信用が置けないので、メソッドの頭とかで一括して弾けたらいいんだけど、
関数(スクリプトで使う奴)の数だけ引数の数に色々種類があってそういう処理をいちいち記述しないといけなくて若干めんどくさい。
(テキストを読み込んで、splitしてSwitchで分岐させたりしてます)
どうにかならんかなぁ。ならないか。
まあ何のために単体テストやるのかって言ったらこういう凡ミスを発見するためだとは思うんだけど、やっぱめんどくさいなあ。
危ないアレ
Re: 危ないアレ
私は、デバッグ情報を出力するモードでのコンパイルはほとんどしませんね。
主にprintf/putsデバッグとかMessageBoxデバッグ、Beepデバッグを使い、
デバッガは最終手段という気がします。(個人の感想です)
主にprintf/putsデバッグとかMessageBoxデバッグ、Beepデバッグを使い、
デバッガは最終手段という気がします。(個人の感想です)
オフトピック
用語解説
・printf/putsデバッグ
主にCUIのプログラムで使う手法。printfで変数の値を確認したり、putsでそこに処理が来ていること、
及びどこで落ちているかを特定したりします。fflush(stdout);と組み合わせた方がいい気がします。
・MessageBoxデバッグ
主にGUIのプログラムで使う手法。MessageBox関数を使用し、そこに処理が来ているかや
変数の値(スコープを切ってバッファを宣言するか既存のバッファを流用しwsprintf関数と組み合わせる)を確認する。
・Beepデバッグ
メッセージ処理やループ処理など、MessageBox関数を使うと大量のダイアログが出て死ぬ場面で使用する。
主にそこに処理が来ていることの確認用だが、音の長さや高さで2~3通り程度の状況を区別することもできる。
・printf/putsデバッグ
主にCUIのプログラムで使う手法。printfで変数の値を確認したり、putsでそこに処理が来ていること、
及びどこで落ちているかを特定したりします。fflush(stdout);と組み合わせた方がいい気がします。
・MessageBoxデバッグ
主にGUIのプログラムで使う手法。MessageBox関数を使用し、そこに処理が来ているかや
変数の値(スコープを切ってバッファを宣言するか既存のバッファを流用しwsprintf関数と組み合わせる)を確認する。
・Beepデバッグ
メッセージ処理やループ処理など、MessageBox関数を使うと大量のダイアログが出て死ぬ場面で使用する。
主にそこに処理が来ていることの確認用だが、音の長さや高さで2~3通り程度の状況を区別することもできる。
最後に編集したユーザー みけCAT on 2013年8月12日(月) 22:53 [ 編集 1 回目 ]
理由: 誤字修正
理由: 誤字修正
Re: 危ないアレ
みけCATさん、コメントありがとうございます。
IDEのデバッガが便利でいつも使ってしまいますね。
>offtopic
printfデバッグ、MessageBoxデバッグはよくやるんですが、Beepデバッグは発想がありませんでした。
確かに音でも通知できますね。コレは便利そうです。
IDEのデバッガが便利でいつも使ってしまいますね。
>offtopic
printfデバッグ、MessageBoxデバッグはよくやるんですが、Beepデバッグは発想がありませんでした。
確かに音でも通知できますね。コレは便利そうです。