RE: 検査例外イケテナイところ

2009-08-09

RE: 検査例外イケテナイところ

なんとなくしっくりこないので。どこがしっくりこないのか自分でも良く分かってないから、しっくりきてないという表明だけしておきます。

検査例外は発生したその場、もしくは直接の呼出し元で処理しない限り、throws に記述せざるを得ない。

そうしない場合、より上位層の throws を追加する必要が出てくる。このような追加、もしくは変更は、中間のクラスの再リリースという手間も必要となる。

これは、明らかに開放閉鎖原則に違反する。
例外について色々と考えてみた - 予定は未定Blog版

開放閉鎖原則に反しているのは、追加・変更の可能性を考慮していない変更前の状態を言うんじゃないかなって思った。十分に開放閉鎖原則を考慮したクラスでは、上のような修正を行う必要はそもそも出てこないはず。

あるいは『throws の縛りがきつい java では、むしろ開放閉鎖原則を強く意識しなければならないのでは』と言い換えることもできるかもしれない。個人的には強すぎるのが気になるところではあるけど。その意味では @Throws アノテーションは賛成するところであります。

あと、あえて throws を追加することを嫌うならば、後は↓のようにしちゃえばいいのかもね。

try {
    doSomething();
} catch (Exception ex) {
    throw UnsupportedOperationException(ex);
}

Permalink | コメント(2) | トラックバック(3) | 02:22

コメント一覧

bleis-tift 2009/08/11 07:46 全ての例外をクラスの設計時に想定できるかと言うと、否です。
なので、検査例外を使うと判断したときから、開放閉鎖原則に則ったクラス設計と言うのは破綻するのではないか、というのが自分の考えです。
検査例外という存在は、非検査例外に変換すると言う方法以外ではどうやっても開放閉鎖原則を壊してしまう存在だ、という考えですね。

@Throws アノテーションは、いろいろと情報を追加できるようにすれば、なかなか面白そうです。
例えば、@Throws アノテーションで指定した例外そのもののみを catch しなければならない制約とか。
まぁ、やりすぎるとメソッドの宣言部分がどんどん重たくなっちゃうのが問題ですね・・・

一番下の例外の変換ですが、それはエントリで行った考察の次の段階ですよね。
「で、どうするか」の部分というか。
まぁ、今のところ一番現実的ではあるものの、まだ検査例外がそこまでして避けるものなのかという結論がでていないので・・・
自分の中ではかなり「避けるべきもの」という認識に傾いてはいますが。

j5ik2o 2010/01/20 12:23 ＞bleis-tift
@Throwsをコンパイル時にapt(Annotation Processing Tool)を使って、経路上のメソッドは透過的に扱いEnd-to-Endの契約のみが妥当かチェックできるかもしれません。コード上でcatchがあるかないかの判定となるといろいろパーサとか作らないといけないのでややこしいですが、、、
http://irenka.ashikunep.org/
irenkaであればコンパイルタイムでJavaコードをDOMに展開できるので、RTEであってもちゃっとキャッチしているかどうかのチェックは余裕でできるんですよ。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/SiroKuro/20090809/1249838522

		2009/08
日	月	火	水	木	金	土
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

SiroKuro Page

2009-08-09

RE: 検査例外イケテナイところ