返す値を一時変数に受けるよりはtry-finally

余計な一時変数というのはなるたけ作りたくないものですが、例えばJavaでこんなコード書いちゃうことあるじゃないですか。

static T poll() {
  Integer result = array[top];                   // (1)
  if (++top >= array.length) top -= array.length;// (2)
  return result;
}

メソッドの戻り値が決まる(1)のが処理完了(2)より前というパターン。Delphiなら無縁な手間なんです*1が、C系の言語だとメソッド抜けるときまで戻り値を一時変数に受けておかないといけません。

こんな無意味な一時変数美しくありませんね。どこか行ってほしいですね。そして幸い、Javaにはそのための道具があります。try-finallyです。
最初のコードはこんなコードに書き換えることが可能です。

static T poll() {
  try { return array[top]; }
  finally { if (++top >= array.length) top -= array.length; }
}

finallyといえばリソースの解放というのが定番ですが、主処理をfinallyの中に突っ込むことで戻り値を確定させたあとに主処理という順番が自然に記述できました。

重くない？

try構文と言えばオーバーヘッドが気になる感覚は健全です。一時変数がいやだという美意識のためにパフォーマンスを犠牲にするのは本末転倒。

しかし本当にパフォーマンスに悪影響があるのか、それは計測してみてから言うこと。実際、ぶん回してみましょう。

一時変数版	6946 ms
try-finally版	6935 ms

結果を見ると、ほとんど差はありません。おそらく誤差の範囲内ですがtry-finallyを使った方がわずかに速いくらい。

実のところ、try構文で気になるオーバーヘッドの正体は、tryブロックの実現ではなくその中で発生する例外オブジェクトの生成コストです。だから、NullPointerExceptionをtry-catchするよりはnullチェックを書けと言い習わされている理由はNullPointerExceptionインスタンスを生成するコストを嫌ってのことです。nullに遭遇する頻度が少ないならむしろtry-catchにした方が条件分岐が減る分パフォーマンスはむしろ向上します*2。

というわけで、try-finally方式を使うにあたってパフォーマンスを気にする必要はありません。