処理の成功・失敗を戻値で返すか例外を使うか

「例外をめぐる雑談 - いぬビーム」の件。 IRCだと前提となるコード貼らずに話だけ進めちゃったりするし、補足とか書くわ。

LLって検査例外ないっぽいから不便

まず本題じゃない方のこっちから。PHPで書いてると

function hoge() throws HogeException
{
    ...
}

って書きたくなる。 Java書いてると逆にthrowsとかうざいって思うんだけど。なんでかというと、関数の呼び出し側でtry-catchを忘れて難儀するとか、そういうことがあるんだよね。

特別な戻値はやだよね

FileInputStreamみたく

try {
    hoge = new FileInputStream(file);
} catch (FileNotFoundException e) {
    エラー処理
}

ってのはよいと思うのね。

hoge = new FileInputStream(file);
if (hoge == null) {
    エラー処理
}

はなんか違うと思う。

処理の成功・失敗は？

これは迷う。 Lock (Java Platform SE 6)のイメージで

if (! lock.tryLock()) {
    ロック取れなかったとき
    return;
}
ロック取った後の処理

なのか

try {
    lock.tryLock();
} catch (HogeException e) {
    ロック取れなかったとき
    return;
}
ロック取った後の処理

なのか。例外方式がいいよねという点は次のように考えたときなんだよね。

total = sum(a, b, c, d, e);

は自然なのだけど、

success = lock.tryLock();

は不自然じゃないか、ということ。これ思いついたときは本当に不自然だと思ったんだけど、「成功か失敗かを戻値で返す関数」ってたくさんあるから、あんまり不自然じゃないと思ってきた。

感覚的な話なのだけど、ファイルを開こうとしたら開けなかったというのはエラーっぽいんだけど、ロックしようとしたらロックできなかったというのは、エラーじゃない感じがする。エラーっぽいときだけ例外にしよう、そういう方針にした方がコードが読みやすいよね、っていうのを以前どこかで読んだのだけど、出典がみつけられなかった。たぶん、ちょっと前まではこの方針でよかったのだと思うのね。

でも別の方針として、数学の関数とか、isHoge(), getHoge() みたいに戻値がありそうなものでない、 tryLock() みたいな戻値のなさそうな字面のものは、字面の通りに値を戻さなくして、その代わりに例外を使うというのも、アリといえばありのような気がする。

でも tryLock() で例外ってのは不自然だと思うけどなあ。 true/falseを返すものだという思い込みがあるからかもしんないけど。

blog.fuktommy.com