140

だから私は今朝、次のようなコードに出くわしました：

try
{
    x = SomeThingDangerous();
    return x;
}
catch (Exception ex)
{
    throw new DangerousException(ex);
}
finally
{
    CleanUpDangerousStuff();
}

これで、このコードは正常にコンパイルされ、正常に機能しますが、特に最終的に関連付けられている場合は、tryブロック内から戻るのが適切ではないと感じます。

私の主な問題は、最終的にそれ自体の例外をスローした場合にどうなるかということです。返された変数がありますが、対処するための例外もあります...それで、他の人がtryブロック内から戻ることについてどう思うか知りたいですか？

4

6 に答える 6

179

いいえ、それは悪い習慣ではありません。意味returnのある場所に配置すると、読みやすさと保守性が向上し、コードが理解しやすくなります。ステートメントが発生したfinally場合、ブロックが実行されるため、気にする必要はありません。return

于 2009-01-16T00:38:42.847 に答える
23

最終的には何があっても実行されるので、関係ありません。

于 2009-01-16T00:34:34.990 に答える
16

個人的には、finally ステートメントの前に return ステートメントを見たくないので、この種のコーディングは避けたいと思います。

私の心は単純で、物事をかなり直線的に処理します。したがって、ドライ ランニングのコードを見ていくと、return ステートメントにたどり着けば、その後のすべては問題ではないと考える傾向がありますが、この場合は明らかにかなり間違っています (return ステートメントに影響するわけではありませんが、どのような副作用が考えられるか）。

したがって、return ステートメントが常に finally ステートメントの後に現れるようにコードを調整します。

于 2009-01-16T04:14:28.417 に答える
13

これはあなたの質問に答えるかもしれません

try{returnx;で実際に何が起こるか }最後に{x=null; } 声明？

その質問を読んだことから、例外がスローされる可能性があると思われる場合は、finallyステートメントで別のtrycatch構造を使用できるように思われます。コンパイラーは、いつ値を返すかを判断します。

とは言うものの、後であなたやこれに気付いていないかもしれない他の誰かを混乱させないように、とにかくコードを再構築する方が良いかもしれません。

于 2009-01-16T00:33:27.520 に答える
6

機能的には違いはありません。

ただし、これを行わない理由は1つあります。いくつかの出口点がある長いメソッドは、多くの場合、読み取りと分析がより困難です。しかし、その異議は、catchやfinallyブロックよりもreturnステートメントと関係があります。

于 2009-01-16T08:37:48.963 に答える
3

あなたの例では、どちらの方法も同等です。コンパイラが同じコードを生成したとしても、私は驚かないでしょう。finally ブロックで例外が発生した場合、return ステートメントをブロック内またはブロック外に配置しても同じ問題が発生します。

本当の問題は、文体的にどちらが優れているかです。return ステートメントが 1 つだけになるようにメソッドを作成するのが好きです。このようにして、メソッドからの流れを簡単に確認できます。したがって、return ステートメントを最後に置くことも好きなので、メソッドの終わりとこれが返すもの。

return ステートメントが最後のステートメントとしてきちんと配置されているため、他のステートメントが来て、複数の return ステートメントをメソッドの他の部分に振りかける可能性は低くなると思います。

于 2009-01-16T01:08:07.373 に答える