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

[Daisuke Sawada <swd@xxxxxxxxxxxxxxxx>]

澤田です。
ここ数日、京都でPerl/Ruby作者様のサインをいただいたり、
舞浜でミッキーのサインをいただいたりしてました(笑)

On Tue, 5 Dec 2000 14:20:52 +0900
in [jfriends-ml 1471] Re: assertion 、事前条件の例外スロー方法
Toru TAKAHASHI <tooru6.takahashi@xxxxxxxxxxxxx> wrote:

> 高橋（徹）です。
> 
> > 前橋です。
> ：
> > 今はもう辿れませんが、昔 Sun の Web サイトにあったJava programmer's
> > FAQ には、Assert の実装例が載っていて、それでは RuntimeException を
> > 投げていました。
> うーん、やっぱりRuntimeExceptionなんですねぇ。。。確かにそのスレッドは
> RuntimeExceptionで終了するのですが、他のスレッド群は生き続けています。
> しかも、RuntimeException時にstackTraceがコンソールに表示されずに消えて
> しまうことがよくあり、ときどき困ったなぁと思うことがあります。
> ＃RuntimeExceptionをスローする際、ログにメッセージを書いてくれれば
> ＃まだましなんだけど・・・ 

マルチスレッドを扱うコードを多人数開発している場合、RuntimeException
で落ちてしまうといったいどこが悪いのか途方に暮れます。ちょっと辛いので、
今書いているコードでは ThreadGroup#uncaughtException() を実装して、
そこに来ちゃったらログを吐くようにしてあります。
派生したThreadGroupを使ってスレッドを作る必要がある点で不便なんですが、
これ以外の解決策はないと思いました。


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

私は、今のJava言語仕様の枠内で事前条件を表現するのであれば
RuntimeExceptionが良いと思いました。事前条件に関する知識と言っても
昔読んだ「オブジェクト指向入門」の記憶ぐらいしかないのですが、
事前条件というのは「それを満たせなければもはや実装は耐えられない」
ことですよね？インタフェースでの事前条件は、その先の実装すべてに
影響を与える（というかそれを前提として実装されている）ので、
「生き続ける」なんてのは奇跡でしかない気がします。
運用中の耐性を上げるのであれば、問題が起きたスレッドにはなるべく
早く止まってもらった方が可能性があると予想します。

checkedな例外の場合は「そういう状態にも一応例外を投げることで耐える
（と解釈が可能な）実装があるし、上位のコードにもそれを要求している」
のではないでしょうか？

Javaでassertかぁ・・時間のあるときにJSR-041を読んでみます。


> >   try {
> >       処理;
> >   } catch (Exception ex) {
> >       ;
> >   }

脱線しちゃいますが、RMIを使っている場合はサーバ側にそういうコードが
必要な場合があります。サーバ側のバグでRuntimeExceptionが起きると、
それがクライアントまで貫通してしまうのです(^^;
RuntimeExceptionならログに出してもっと違う例外にすりかえるとか、
Errorだったらクライアントには違う例外を投げて、サーバは駄目もとで
シャットダウンを試みるとか・・。


> Javaの入門書や雑誌にこんなコードがあふれているのが問題・・・
> それを見て、平気でこんなコードを書くようになってしまう。
> ちょっと面白いWebページがありました。
> 「勉強用のサンプルは低レベルなものが多い」
> http://www.st.rim.or.jp/~k-kazuma/SD/SD201.html
> エラー処理の話しではないですが、開発環境や雑誌のサンプルをまねてしまう
> 問題が載っています。

勉強用というわけではないのですけど、何らかのフレームワーク
（そこまでいかなくても普通のクラスでも同じかな）を提供するときに、
その使用サンプルコードには非常に気を使いますね。サンプルを簡潔に
すればするほど「単にそう書けば大丈夫」と思えるコードになるので、
仕様を理解する事なくそのサンプルを引用されてしまうようです。

___
澤田　大輔(die)
email: die@xxxxxxxx(home), swd@xxxxxxxxxxxxxxxx(office)