[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 1474] Re: assertion 、事前 条件の例外スロー方法

前橋です。

高橋さん:
>「達人プログラマー」の22節死んだプログラムは嘘をつかない
> ヒント32：早めにクラッシュさせること
>ですね。ろくな結果がでないだけでなく、バグがある場所がどこか分かり
>にくくしてしまいますね。

その通りだと思います。

ところで、「達人プログラマー」とは書籍でしょうか?
読んでみたいような... よろしければ詳細を教えてくださいませ。

>> だから、assertでは、RuntimeExceptionを投げるどころか、スタックトレースを
>> 吐いてSystem.exit()しちゃってもいいぐらいだと思います。JavaOSで動いてる
>> とかでなければ。
>開発・デバッグ時はそうなんですが、運用中はたとえバグが原因であっても
>止まってほしくないのです。生き続けられる限りは生き続けて欲しい。。。
>その代わり、詳細な情報をログに吐いておかないと、後でバグを究明できな
>くなりますが。

バグありプログラムをとっとと殺すのは、原因究明のためもあります
けど、「さらにろくでもないことをしでかす前に殺してしまえ」という
のもあるわけです。

たとえば CADで形状設計をしていて、ある時突然 System.exit() して
半日分の作業内容が吹っ飛んだらユーザさんは悲しいですが、
半年かけて作ったデータがバグのおかげで「よれていて」、後工程に
回せなかったら、もっと困るように思います。

実際のところ、後者のようになるのは確率的には低いわけで、
年に1回、データがよれて決定的に困るのと、1日1回 System.exit()で
コケるのと、どっちが困るのかといえば後者かも知れませんが、
1日1回コケるような代物は出荷しちゃいけないわけで、
System.exit()を大量に入れたコーディングで、通常の使用では
まずコケないレベルまではデバッグすべきでは? と思うわけです。

UNIXのカーネルは、決定的におかしいと思ったときにはpanic()しますよね。

>> もちろん、呼び出され側である程度の処理をしないと引数の妥当性が
>> わからない、だから、呼び出し側では、とりあえず呼んでみて
>> IllegalArgumentExceptionをcatchする、というケースは話が別ですが。
>うーん、これはまずいです。エラーチェックはやっぱり呼び出し側で
>行わないと。。。妥当性をどうしても相手側に判断してもらわなければ
>ならない場合は、妥当性チェックメソッドを用意すべきと思います。

はい。この例は、「こういう場合ならIllegalArgumentExceptionをcatch
するのも妥当だろう」という例で挙げたので、こういう場合自体を避ける
なら、それはそれでよいと思います。

でも、マルチスレッド環境では、妥当性チェックメソッドではまずい
こともありそう。

>> Javaの場合、基本的に領域破壊はないので、「あっちの方はバグってる
>> けど、こっちはまだ元気」ということを期待してもよいのかもしれません。
>これはC/Javaというよりか、モジュールの作り方・独立性によると思います。
>他のクラス(インスタンス)を利用しまくっていれば、壊れたインスタンスを
>呼び出してしまうわけですし（壊れたインスタンスからも呼ばれるなぁ。。。）

うむむ。C の場合、どんなにきれいにモジュール分けしても、
同一実行形式にリンクされている限り、ちょっと配列がオーバランしたり
するだけでよそのモジュールだろうがなんだろうが簡単にぶっ壊して
くれますから、やはり危険度は違うように思います。

>>   try {
>>       処理;
>>   } catch (Exception ex) {
>>       ;
>>   }
>> 
>> こんなことされてちゃ困るなあ... そのぐらいならいっそ、Errorを
>> 投げる方がより確実かも。
>Javaの入門書や雑誌にこんなコードがあふれているのが問題・・・
>それを見て、平気でこんなコードを書くようになってしまう。

せめて、

  try {
      処理;
  } catch (Exception ex) {
      ex.printStackTrace();
      System.exit(1);
  }

こうなっていれば、私なら許すんですが。

>ちょっと面白いWebページがありました。
>「勉強用のサンプルは低レベルなものが多い」
>http://www.st.rim.or.jp/~k-kazuma/SD/SD201.html
>エラー処理の話しではないですが、開発環境や雑誌のサンプルをまねてしまう
>問題が載っています。

ぎくっ!

ああ、でももう金曜には印刷に回されてしまう...　(^^;

>フレームワーク側にどこまで強度さ（頑健さ）を求めるかにもよりますが。
>危ないプログラムは排除するような仕組みはおもしろそうです。
>次世代の言語ではこのような機構があるといいな。。。
>＃Unsafe Programming Exception: このクラスはフレームワークを
>＃誤って使っています。アンロードされました。

Javaなら可能なような気もするのですが。

スタック上に、フレームワークとアプレットが交互に積み重なるような
形になってしまう場合の対応をきちんと決めておけば...

------------------------------------------------------------
  前橋 和弥              maebashi@xxxxxxxxx
                         http://member.nifty.ne.jp/maebashi/
------------------------------------------------------------