SiroKuro Page

自分はよくこうする。

try {
    Writer out = new BufferedWriter(new FileWriter("ファイル名"));
    try {
        // なんやかんや
    } finally {
        out.close();
    }
} catch(IOException e) {
    e.printStackTrace();
}

まあ、これだと結構深刻な欠点があるんだけど。

Permalink | コメント(5) | トラックバック(0) | 17:51

コメント一覧

ryoasai 2011/02/26 18:39 なるほど、このイディオムは知りませんでしたが便利ですね。一見問題が無いようですが、深刻な欠点とはどこなのでしょうかね？catch節でoutのスコープが外れていることと、close()時とそれ以外の例外の区別ができないことかな。

ryoasai 2011/02/26 19:32 あと、入力と出力のようにストリームが複数ある場合は使えないみたいですね。

SiroKuro 2011/02/26 21:46 finally からは例外をスローしてはいけません。finally 時に例外が起きると try で起きた例外が上塗りされて catch できませんから。FindBugs でも検出対象じゃなかったかなー。
この書き方は Close や Dispose が例外を排出しない C# で良く使われる書き方ですね。using ブロックを伴って。

katzchang 2011/02/28 02:45 自分もこのやり方をよく使います。null初期化が気持ち悪いから避けたいだけなんですが…。

そもそも、複数の例外が発生した場合ってどう管理すべきなんでしょうか？現実的には、片方をログに出しておきつつもう片方をフレームワークに投げておいて、といった対応になるんでしょうけど、この辺りの上手い（もしくは定番の）やり方があったら知りたいです。

これは、try-finallyをネストさせない方式でも問題になるはずです。finallyでの例外上書きが問題なら、finallyないでtryさせればいいだけですし（その場合の"if (out == null)"が不要になるだけでも、こっちの記述の方が好きです）。

SiroKuro 2011/02/28 02:48 どっちかというと自分は初回の例外が欲しいところです。２回目はたぶん要らない子。

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

トラックバック - http://d.hatena.ne.jp/SiroKuro/20110226/1298710304

idトラックバック

		2011/02
日	月	火	水	木	金	土
		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

SiroKuro Page

2011-02-26

■