c# 例外の重複・改

質問

こんにちは。なんとなく質問が上手でないc#初心者です。

　この前になんと言うか、聞き方が悪かったのか、理解力が足りなかったのか、しっくりこない回答しかもらえなかったのですが、GoF本を読んだら新しい見方を学んだので再挑戦（質問）します。

　単刀直入にいうと、Decoratorパターンや, Proxyパターンで「装飾、フックを行うメソッド(MethodA)」はその「装飾、フックされるメソッド(MethodB)」で行われているものと“同じ”例外のチェックを行うべきですか？　という質問です。

void MethodA(int val) {
　　if ( valに関する条件A )
　　　　throw new ArgumentOutOfRangeException("val");
　　MethodB(int val);
　　…… // 処理
}
----------------------------
void MethodB(int val) {
　　if ( valに関する条件A )
　　　　throw new ArgumentOutOfRangeException("val");
　　…… // 処理
}

　言い換えると、まったく同じ例外のチェックを重複させる意味はあるのか？　という意味です（もしかしたら僕以外の人には当たり前すぎて話にならないかも知れませんが）。以前はJavaの標準ライブラリではまずいかもしれないと言われました（何のことやらサッパリです）。

　以前と質問内容が変わっていない気もしますが、とりあえず
１、意味の有無
２、　１が有の場合、動作の変化、バグ等
　を今回の質問内容とします。

　どなたかご存知の方、または「こう思う」という方がいらっしゃいましたらご意見を伺わせてください。

回答No.3

Yune-Kichi · ベストアンサー

メソッドのContractなのだから行うべきかと。
自身の処理の一つとしてのpre-conditionのチェックという位置づけになります。
つまり，動作が変化する等の理由では無く，メソッドの自己記述の完結性が理由です。

他には，CodeContracts使って
Contracts.Requires<ArgumentOutOfRangeException>(!valに関する条件A);
とすることもあるかと。
これには，Code Contracts EditorがMethodAでもContractを拾ってくれる，という効果もあります。

さらに，これがinterfaceの同一メソッドであれば，interface自体のContractですので，
そちらのContractClassに条件を書いてしまい，実装側にはContractを書かない，という解もあります。
# CodeContractsのRewriterが両方に書いてくれます。

お礼

いつもいつも回答ありがとうございます。

　Contractですか。調べたところ、リライターで取り除くので実行速度は影響されないとか何とかありましたが、今度挑戦してみることにします。

　とりあえず、チェックを契約と見なすと行うべきということですね。貴重なご意見、ありがとうございました。

回答No.2

nak777r

ステップ実行して、確認すればわかりませんか？
Aのパターンをステップ実行してみる
Bのパターンをステップ実行してみる
Aのパターンの例外処理が行われるような処理をしてみる
Bのパターンの例外処理が行われるような処理をしてみる

Aのパターンで例外処理を行っている、
Bのパターンで、Aの例外処理はおこなわれるの？
的な疑問はステップ実行するだけで判るでしょ

それらをやった上で、例外が必要なら、例外にさせない
方法を共通化できないかを考えて見ればいいのではないですか
Aのパターン、Bのパターンで例外にならないための
チェック関数を作成してそれぞれの関数内で呼ぶとか
関数をコールする前にチェックするとか

お礼

回答ありがとうございます。

> ステップ実行して、確認すればわかりませんか？
　ステップインは結構使っています（というか、ステップオーバーするところまで間違えてインいてしまって、深くなりすぎて面倒になったり……）。

　MethodA（かそのクラス）に[System.Diagnostics.DebuggerStepThrough]を付けたらどちらにせよ、外部からは（ステップインしようとしてもできないので）MethodAが例外を吐いているように見えると思ったので、別にMethodAにチェックをつけなくてもいいかと思ったのですが…間違いでしょうか？

回答No.1

wormhole

なんのために

>　　if ( valに関する条件A )
>　　　　throw new ArgumentOutOfRangeException("val");

のチェックを行ってるかによるのではないでしょうか。
MethodB()を呼び出す前の事前チェックというだけなら意味はないでしょうし、
MethodB()より後の処理のためのチェック処理なら意味はあると思いますし。

お礼

回答ありがとうございました。

　なるほど。それもそうですね。
　チェックを他のメソッド任せにするのはそのメソッドが何らかの変更が加えられたり、（普通ないと思いますが、どこかで下位クラス代入されてたりして）オーバーライドされ、条件がゆるくなったメソッドが呼び出されたら大変ですよね。