返品後に作業を行うためのfinally節の使用は、スタイルが悪い/危険ですか？

イテレーターの作成の一環として、次のコードを作成していることに気付きました（エラー処理を削除）

public T next() {
  try {
    return next;
  } finally {
    next = fetcher.fetchNext(next);
  }
}

読むよりもやや読みやすい

public T next() {
  T tmp = next;
  next = fetcher.fetchNext(next);
  return tmp;
}

私はそれが読みやすさの違いがそれほど圧倒的ではないかもしれない単純な例であることを知っていますが、例外が含まれていないこのような場合にtry-finallyを使用するのが悪いかどうかについての一般的な意見に興味がありますコードを簡素化するときに実際に優先される場合。

悪い場合：なぜ？スタイル、パフォーマンス、落とし穴、...？

結論 あなたのすべての答えに感謝します！（少なくとも私にとって）結論は、最初の例は一般的なパターンであれば読みやすかったかもしれないが、そうではないということだと思います。そのため、目的外の構造を使用することで生じる混乱と、場合によっては難読化された例外フローが、単純化よりも重要になります。

個人的には、コマンドクエリ分離のアイデアを考えます。すぐにわかると、next（）には2つの目的があります。広告されたnext要素を取得する目的と、nextの内部状態を変更する隠れた副作用です。だから、あなたがやっているのは、メソッドの本体で公示された目的を実行し、finally節の隠された副作用に取り組むことです...

要するに、コードがどれほど理解しやすいかということです。この場合、答えは「meh」です。単純なreturnステートメントを「試行」してから、フェイルセーフエラーリカバリ用のコードブロックで隠れた副作用を実行しています。あなたがしているのは「賢い」ことであり、「賢い」コードはしばしばメンテナーに「なにが…なんてことだと思う」とつぶやくように誘います。あなたのコードを読んでいる人々が「うん、うん、理にかなっている、はい...」とつぶやくのに良い

それでは、アクセサコールから状態突然変異を分離したらどうなるでしょうか？あなたが懸念している読みやすさの問題は議論の余地があると思いますが、それがあなたのより広い抽象化にどのように影響するかわかりません。とにかく考慮すべきこと。

純粋にスタイルの観点から、私はこれらの3行を考える：

T current = next;
next = fetcher.getNext();
return current;

... try / finallyブロックよりも明確で短い。例外がスローされることを期待していないので、tryブロックを使用すると人々を混乱させるだけです。

それはfinallyブロック内のコードの目的に依存します。標準的な例は、読み取り/書き込み後にストリームを閉じることです。これは、常に行わなければならない「クリーンアップ」のようなものです。オブジェクト（この場合はイテレータ）を有効な状態に復元すると、IMHOもクリーンアップとしてカウントされるため、ここで問題は発生しません。return戻り値が見つかったらすぐにOTOHを使用し、finallyブロックに多くの無関係なコードを追加すると、目的がわかりにくくなり、理解しにくくなります。

「例外が含まれていない」場合は、問題なく使用できます。コードがスローできるだけで、それらを処理する予定がない場合は、try...finallyaなしで使用するのが非常に一般的です。場合によっては、finallyは単なる保護手段であり、プログラムのロジックについては、例外がスローされないことがわかっています（従来の「これは絶対に起こらない」条件）。catchRuntimeException

落とし穴：tryブロック内で発生した例外により、ブロックがfinally実行されます。これにより、一貫性のない状態になる可能性があります。したがって、returnステートメントが次のようなものである場合：

return preProcess(next);

このコードは例外を発生させ、fetchNextそれでも実行されます。OTOHのようにコーディングした場合：

T ret = preProcess(next);
next = fetcher.fetchNext(next);
return ret;

その後、実行されません。tryコードは例外を決して発生させないと仮定していることを知っていますが、これよりも複雑な場合はどうすれば確認できますか？イテレータが長命のオブジェクトである場合、現在のスレッドで回復不可能なエラーが発生しても、イテレータは常に有効な状態を維持することが重要であるため、既存のオブジェクトは存在し続けます。そうでなければ、それは本当に重要ではありません...

パフォーマンス：そのようなコードを逆コンパイルして内部でどのように機能するかを見るのは面白いでしょうが、JVMについて十分な知識がなく、十分に推測することもできません...例外は通常「例外的」なので、処理するコードは速度を最適化する必要はありません（したがって、プログラムの通常の制御フローで例外を使用しないようにアドバイスする必要があります）が、私は知らないfinally。

タイトル文：「...帰国後に作業を行うための最終節...」は偽です。finallyブロックは、関数が戻る前に発生します。それが実際に最終的に重要なポイントです。

ここで悪用しているのは評価の順序です。ここで、nextの値は、変更する前に戻るために保存されます。これは一般的な慣行ではなく、私の意見では間違っているため、コードが非シーケンシャルになり、従うのがはるかに難しくなります。

finallyブロックの用途は、スローされる例外に関係なく何らかの結果が発生する例外処理です。たとえば、リソースのクリーンアップ、DB接続のクローズ、ファイル/ソケットのクローズなどです。

（一般的に、あなたの例ではなく）tryの一部が例外をスローする可能性があるため、私は本当に慎重です。望まないときに実行します。

そして、他のワームの缶は、一般に、最終的にいくつかの有用なアクションが例外を投げることができるので、あなたは本当に厄介な方法で終わることができます。

これらのため、それを読んでいる人はこれらの問題について考えなければならないので、理解するのはより困難です。