質の高いプログラムの続きです。
止まらないプログラムなんて当たり前の話なのですが意外と盲点もあります。
PCアプリでは滅多にありませんが機械制御などでよく使われているエアーシリンダーを例にします。
エアーシリンダーとはソレノイドバルブ(電磁弁)をコントロールして高い圧力のエアーを送ったり止めたりします。
エアーが送られるとシリンダーが動作します。
エアーを止めるとその場で止まったり戻ったりします。
エアーシリンダーにはセンサーが付いており、制御ソフトはセンサーのON-OFF信号で位置を把握します。
プログラムは単純にソレノイドバルブをONしてセンサーがONしたら処理終了とします。
まあ、何てことのない制御ですが、例えば外部から引いたエアーに問題があったりエアーホースが外れたりしたらソレノイドバルブをONしてもエアーシリンダーは動きません。
ソレノイドバルブを制御する線が切れていたら当然動きません。
これが前回書いた「ワーストケース」に相当します。
私の場合、このような制御器機を動作させる時は必ずタイムアウト時間を設けます。
タイムアウトの制御を入れないといつまで経っても次のステップに行けずダンマリになって、使用者から見たら「プログラムが止まった状態」になってしまいます。
コレ以外とあるんです。デバッグの時はエアーにトラブルが出たりしないので見落としてしまうんですよね。
あと昔あったのではWindowsアプリケーションをC++で作っていてWindowsAPIを使いまくってたアプリでbool型の戻り値を無視してた人がいました。
まあ、実際に戻り値がfalseだった事は一度もありませんが、もし戻り値がfalseだったら...
それを指摘したところ「後からif文を入れる予定だった」と言ってましたが、大量にあるbool判定に後からif文を追記するなんて面倒だと思います。
それに見落としも必ず出てきそうです
そんなリスキーなプログラムを作るなら最初からきちんと作った方が安全です。
もう1つ
昔二人で作ったWindows用C++プログラムがありました。
納入先は日本メーカですがアメリカにある工場です。
稼働してから2ヶ月後にアプリが落ちるから見てくれと依頼が来ました。
症状から相方が作った部分だと確証できたのですが、上司からスキルの高い方という訳のわからない理由で私が行くことになりました。
原因はすぐ判明しました。
やはりチェックの手抜きで動的配列の要素範囲外を見て落ちるといった単純なものでした。
少しのミスでアメリカまでの往復旅費と私の出張費(客先から1ヶ月は見てくれと言われ暇な滞在)、たぶん100万円前後のお金が飛んだんではないでしょうか。
ちょっとしたミスで甚大な出費が出る事もあるという例でした。