【C#/Java?】try-catchでcatchせずにfinallyは一般的？

質問

普段はJavaを使っているのですが、故あってC#のソースを簡易レビューすることになりました。

C#を始めてそれほど間もない人間の書いたソースなのですが、以下のようなソースをたびたびみかけます。

try
{
　　// 処理
}
finally
{
　　// finally処理
}

C#の場合、Javaとは異なり全ての例外はJavaで言うところの非チェック例外であると認識しています。（ただし、Javaの非チェック例外と同じ扱いをしていいとは思っていませんが……）
呼び出し元に起きうる全ての例外処理を任せるがfinally処理をしたいならば、このような書き方をするのが一般的なのでしょうか。

Javaの場合でもこのような書き方ができることは確認しましたが、Javaの場合は非チェック例外が起きる＝バグであることがほとんどなので、このような書き方をする場面はあまりないように思います。
（もちろんチェック例外もthrowsを書けば同じように書くこともできるとは思いますが、自分ならやらないですし、そのようなソースを見たこともないです）
ですので、単に自分がJavaを普段使っているからcatchがないことに違和感を感じるだけなのであれば、この問題はスルーしたいと思います。

C#経験者が周りにいない状況ですので、皆様のお知恵をおかりしたいと思います。よろしくお願いします。

回答No.2

SN1701 · ベストアンサー

Javaの場合ですが、わたしは、よくこの書き方をします。

チェック例外でも、非チェック例外でも、例外処理を呼び出し元に任せるような設計にすることはあると思います。
呼び出された方では、例外の処理方法が決められないようなケースではcatchしないし、その場で処理すべき例外ならcatchするようにします。

例外をcatchするべきかということと、finallyで何らかの回復処理をしなければならないこととは、そもそも別の話なので、finally節だけになることがあるのは、自然なことだと思います。
finallyだけということは、finallyですべきことはあるが、そこでは例外をcatchすべきでないからcatchが無いと考えた方がいいでしょう。
逆に用もないのにcatchするのはよくないです。

お礼

回答、ありがとうございます。
よくよく考えてみれば、本当に仰る通りですね。

どうも自分がこれまで「try-catch、もしくはtry-catch-finally」と頑なに考えていた部分があるように思います。
これまで作ってきたものが、「起こった例外を別の例外でラップしてthrowする」という設計であったのも、
この考え方を固めてしまった原因のように思います。
catchしたものをそのままthrowするだけなら、throwsを書いてcatchしなければいいわけですよね。

どちらにせよ、例外処理は設計時の重要な項目ですから、この機会に深く掘り下げておこうと思います。

回答No.1

equinox2

>呼び出し元に起きうる全ての例外処理を任せるがfinally処理をしたいならば、このような書き方をするのが一般的なのでしょうか。

この方法でエラー発生の際の処理が全て記述できるなら、この方法が
一番シンプルだと思います。

以下の2008/12と2009/1に同様な内容の記述があります。
http://blogs.msdn.com/nakama/

ただ、物事には例外があって、業務エラーに類する物については、
呼び出し元に戻してしまえば良いとは一律には決められないので、
エラーの種類によっては、その場で catch する必要のある場合も
存在します。
(例）・ユーザ入力によるDBキー重複 → 知らせて再入力を促す
　　 ・DBのロックタイプアウト　→必要に応じてリトライ

私は、以前は以下の判断基準でエラー処理を統一させていました。
(1)想定できるエラー（業務エラーに多い）はその場でエラー処理
(2)想定できないエラーは呼び出し元に渡す（catchしない or Throw）

(1)のケースを限定して適用し、それ以外は Catch しない というのが
実用的かも知れません。

お礼

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

リンク先のブログ、非常に興味深く読んでいます。（現在進行形）
量も量ですし、かなり重要なポイントだと思うので、じっくり理解したいと思います。

Javaを普段扱ってる人間から見るとちょっと違和感のある記述でも、
equinox2さんのような意見やリンク先のブログなどを見ると「なるほど」と思いますね。

是非他の方の意見も聞いてみたいので、もうしばらく意見を募集してみたいと思います。