だから今朝、次のようなコードに出くわしました。
try
{
x = SomeThingDangerous();
return x;
}
catch (Exception ex)
{
throw new DangerousException(ex);
}
finally
{
CleanUpDangerousStuff();
}
これで、このコードは正常にコンパイルされ、正常に機能しますが、特に関連付けられた最終的なものがある場合は特に、tryブロック内から戻るのは適切ではないと感じます。
私の主な問題は、がそれ自身の例外を最終的にスローするとどうなるかです。あなたは返された変数を持っていますが、処理する例外も持っています...だから私は他の人がtryブロック内から戻ることについてどう思うか知りたいですか？
回答:
いいえ、それは悪い習慣ではありません。return意味のある場所に置くと、可読性と保守性が向上し、コードが理解しやすくなります。ステートメントが検出finallyされた場合にブロックが実行されるので、気にする必要はありませんreturn。
finallyは何があっても実行されるため、関係ありません。
これはあなたの質問に答えるかもしれません
try {return x;で実際に何が起こるか }最後に{x = null; }ステートメント？
その質問を読むと、例外をスローする可能性があると思われる場合は、finallyステートメントに別のtry catch構造を含めることができるようです。コンパイラーはいつ値を返すかを判断します。
とはいえ、とにかくコードを再構築して、後であなたやこのことを知らない誰かを混乱させないようにした方がいいかもしれません。
機能的には違いはありません。
ただし、これを行わない理由は1つあります。複数の出口点を持つ長いメソッドは、多くの場合、読み取りや分析がより困難になります。しかし、その反対は、catchやfinallyブロックよりもreturnステートメントに関係しています。
あなたの例ではどちらの方法も同等ですが、コンパイラが同じコードを生成したとしても、私は驚くことはありません。finallyブロックで例外が発生した場合、returnステートメントをブロック内に置いても、ブロック外に置いても、同じ問題が発生します。
本当の質問は、文体的にどちらが良いかです。returnステートメントが1つだけになるようにメソッドを書くのが好きです。これにより、メソッドからのフローが見やすくなり、returnステートメントを最後に置いて、メソッドの終わりとこれが返すもの。
最後のステートメントとして整然と配置されたreturnステートメントを使用すると、他のユーザーが来て、メソッドの他の部分に複数のreturnステートメントを振りかける可能性が低くなると思います。
x、tryブロックの外側で宣言する必要がないことです。宣言を使用に近づけることができます。