エラーの話題
エラーの分類
- page0009の(9)や(13)で、エラー処理の話を書いた。エラーと言ってもいろいろ種類があって、これを同列に議論するのはいけないと思う。
- (1-1) 事前に簡単にチェックできそうなもの
- (1-2) 事前の予知が難しいもの
エラーはどのように処理するべきか
- (2-1) たとえばx86では、シフト命令でシフト回数にCLレジスタを指定することができる。しかしCLが32を上回った時どうなるのかというと、なんとCLを「32で割った余りの回数」だけシフトするということになっている。
- この仕様は自然ではない。たとえばシフトしすぎで結果が0になるとかならまだわかる。
- まあCPU設計者の気持ちとしてはこういう仕様にしておけばCLのうちの5ビットだけを見ればよいということなのだろう。問題はハードウェアの複雑さにも影響するのでこれはやむを得ないのかもしれない。
- しかしなんにせよ、こういう感じの仕様はOSECPUでは許されない。・・・OSECPUなら、32以上が指定されたらエラーである。その方がずっと親切だ。もし32で割った余りで処理してほしいのなら、呼び出し元がそうすればいいだけのことなんだから。
- (2-2) 他にも、たとえば表示域が20文字しかない状況で、100文字の表示を要求されて、その場合ははみ出した部分は適当に切り詰めて画面外に出ないようにするという仕様があったとする。これもよくない。これも20文字以上だったらエラーにするべきだ。
- (2-3) 勝手に丸めてエラーが起きないような状況にするというのは、気が利いているようで実は気が利いていない。エラーはもっと積極的におこすべきだ。丸めてほしいのなら呼び出し元が明示的に丸めればよい。
- なぜこんなことを言うのかというと、もしかしたらそれは不具合やバグのきっかけかもしれないからだ。それを「勝手に」気を利かせて、ごまかしてしまえば、不具合に気付くのが遅れる懸念がある。これはOSECPUの考え方に合わない。だからダメなのである。
- (2-4) エラーを検出した場合、とにかく止まってしまうのが一番いいように思う。不具合なのだから継続はできない。たとえばログに残して適当に丸めて実行を継続したりすると、気づけないかもしれない。なんというかそういう扱いにするとC言語の警告みたいに扱われて、結局は無視されてしまうだろう。
- エラーで止まる場合、メモリ上の内容が破棄されて復元不能になっているのはいただけない。これはOSで何とかする必要がある。逆に考えて、もしエラーで止まってもデータが何も失われないのであれば、エラーで実行を止めてしまうことは怖くなくなる。そうすれば容赦なく止めてしまえと思うようになるだろう。だから失わない方法を検討したい。エラー時のデータが残っていれば、エラー原因を探るのも容易だ。
こめんと欄
- このページにこめんと欄はありません。このページの内容にコメントしたいときはimpressionsにお願いします。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
