2009年01月15日
try-finally
先日書いたgotoの件の続き。
finallyで代替せよという意見もあるけれども、そもそも例外発生の可能性がまったくないコードに対してtry-catch-finallyを書くことには、私はどうしても抵抗を感じてしまう。
そうそう。背中がモゾモゾしますよね。
Java屋的感覚で言えば、try-finallyとtry-catch-finallyは別物ですね。
同一視するから背中がモゾモゾするのでしょう。
これは恥ずかしながら、まさに同一視していたことを反省。
Javaでtry-finallyが文法上有効なのはもちろん知っていたが、tryはcatchとあるものだとばかり考えていたので、finallyブロックを実行させるためにtryを書くことはあまり積極的に考えていなかった。(ちなみに私はC++の経験はほとんどありません)
実に不勉強だった。
Javaで書くとこのようなコードになるのだろうか。
public String getSystemValue(String key) {
// すでに読み込み済みデータの場合はそのデータを使用
String value = null;
try {
this.getLogger().debug("start");
value = this.findCache(key);
if (value != null) {
return value;
}
// DBから取得
value = this.getDao().read(key);
if (value != null) {
return value;
}
// 設定ファイルから取得
value = this.getConfig().get(key);
} finally {
this.getLogger().debug("end(value=" + value + ")");
}
return value;
}
確かにtry-finallyで書けば、途中returnで抜けなければならないことを除けば、これでいいかもしれない。
気になる点を挙げるとすれば、2点。
- tryブロックで生じるコスト
- RuntimeExceptionが出てもログが出てしまう
try-catchのコストは、もはや無視できるレベルらしい。
ただ、Effective Javaに書かれているような、「try-catchブロック内にコードを書くことは、書かれない場合に最新のJVM実装が行うある種の最適化を排除します。」などの記述を見ていると、今回のような用途にわざわざtryを書くことはやはり大げさな気もする。(この話はtry-catchだけの話で、catchブロックを書かなければ当てはまらないのかな。)
前のエントリーで、「例外発生の可能性がない状況下で」と書いたが、RuntimeExceptionが発生した場合もログが出るので、キャッチして再スローするしかない。
Effective Javaに書かれていることも、今読み返すと忘れていることも多いような気がする。
トラックバックURL
この記事へのコメント
みねこあさんのところで、try-catchの件、同じく勉強させて頂きました。
ところで、24行目の return 文は tryブロックの最後ではなく、ここで宜しいのでしょうか。
9行目のreturn valueからの遷移はどうなるのでしょうか。
最後のreturn文は、tryブロックの最後でも問題ありませんし、このコードのままでも支障はありません。
私はできれば途中でreturnするコードをできるだけ書きたくないのでこうしています。
9行目のreturn文に到達した場合、21行目のfinallyブロックが実行されてから、このメソッドを抜けることになるはずです。
