「新幹線不通の原因はHDDトラブル＋システムのプログラムミス」記事へのコメント

プログラムの 40% はエラー処理

[Anonymous Coward]

って話が昔読んだ本に出ていた。

それ以来、関数／手続き呼び出しで、エラー状態がチェックできるものは 全てチェックする事にしている。

そんな話じゃないの？

イマドキは処理速度が足りないなんて話はそう無いと思うし、プログラムは ロバスト側に最大限に振る位で良いのではないかな。

確かあれは Eiffel の本 [fukkan.com]だったと思う。 第 2 版が出ているが、あの厚さに負けて未読。

Re:プログラムの 40% はエラー処理

[Anonymous Coward]

さらに残りの 60%中 の８割は「プログラムが為すべき処理」ではなく、
「為すべき処理が行える状態にあるかどうかをチェックする処理」だったりするのもよくある話で。

Re:

[Anonymous Coward]

なるほど、それら処理をするためにIEの容量が大きくなったんですね！

Re:

[Anonymous Coward]

もしソフトウェア側で全てチェックするとしたら
すべてのアクセス（含メモリ）でエラー処理を行う事に。
ハードもOSも自らの処理も疑う
qmail並みに疑心暗鬼なものになる？
現実的な落とし所は難しい

Re:

[Anonymous Coward]

フレーム問題ですな。無限の可能性に対処するには無限の処理時間がいる。
小心者の私は最大限にロバストにふるなんてそうそう簡単には言えません。

Re:

[Anonymous Coward]

どこにぶら下げるか悩ましいですがこの辺で.

フレーム問題というか,
要求/開発側ともになにが正しいのかを定義してないんじゃないかな？
あらゆる問題をチェックするのはそもそも何が問題かが はっきりしてないと出来ないし.

Re:

[Anonymous Coward]

>要求/開発側ともになにが正しいのかを定義してないんじゃないかな？

ヤブ蛇の極地ですな

Re:プログラムの 40% はエラー処理 ==（追記させてもらいます）何が正しく 何が問題か。

[Anonymous Coward]

プログラム屋さんは、ハード仕様を2進数のような状況で理解しようとする。
ハード屋さんは、プログラムを処理結果で理解しようとする。
その結果、今回のような状況が発生したようにも思うのですが、
今回の設備のシステム設計・開発に携わった諸氏の中に、一人でも、この不具合を成るべくしてなったと考えておられる方がいる事を信じています。
それにしても、
制御設備では、CPU制御が当たり前になっている中で、９９．９％の稼動をCPU制御で保障するって不可能なんだろうか？
今回のようなCPU制御での構成部品がトラぶった時にも確実に稼動継続できる設備なんて。

Re:

[Anonymous Coward]

戻ってきた結果に対してのチェックで、正常・異常のほかにその他の処理が抜けている場合が多い。