検査例外嫌いを表明するエントリ

寝る前にメモ書き。2010-09-29を見ていて思った。

Javaの方がひどいんじゃないか。

特殊な例を除いて型推論なんて存在しないし(あるだけマシ)、try catchで変数のスコープが無駄に広くなる点では同様。検査例外の関係でtry cathまたはthrowsを強制される。参照先で言うところのhoge.YYY();が検査例外を投げるので、catchでもtry catchしないといけない。(コードは記憶で書いているので適当です)。

FileInputStream fis = null;
try {
    fis = new FileInputStream(file);
    fis.read();
} catch (IOException e) {
    if (fis != null) {
        try {
            fis.close();
        } catch (IOException ignore) {
            // 何このどうしようもない状態
        }
    }
}

C#は検査例外じゃないから無視するという選択肢がある。例外はあくまで例外的に発生するものであって、データベースサーバが落ちているので発生する例外などは、どこかしらで処理しなきゃいけないけど、発生する例外の大半は事前の検査で回避できるものだと思う。

例外はなるべく回避できるようになっている。例えば、int.Parseは例外を投げるがint.TryParseであれば例外は投げない*1とか、キャストは例外を投げるが、asは例外を投げないとか。

本当に必要な場面以外ではtry catchを書かなくて済む。だから、そんなには気にならない。

なんて意見はダメかな……。

見返していて気づいたこと。closeはfinallyで書く。JavaはProject CoinのARMが待ち遠しい。C#のusingは良い。

追記。以下のようなコードの方が変数のスコープの問題（変数をnullで初期化している箇所やnullチェックしている箇所など）の観点からは良いようです。どちらにせよ、見やすいコードとは感じられませんが……。

try {
    FileInputStream fis = new FileInputStream(file);
    try {
        fis.read();
    } catch (IOException e) {
        // FileInputStreamのread()の例外
        try {
            fis.close();
        } catch (IOException ignore) {
            // 何このどうしようもない状態
        }
    }
} catch (FileNotFoundException  e) {
    // FileInputStreamコンストラクタの例外
}

*1:正直、bool Try*(out result)系のメソッドは好きじゃないけど……