3

getBarチェック例外をスローするメソッドを想定します。のインスタンスを取りますFoo。Foo はコード内の他の場所では決して使用されず、例外をスローせず、その唯一の仕事は へのパラメーターになることgetBarです。footry の内部または外部で宣言および初期化する必要がありますか? 質問を拡張する - 内部のコードはtry最小限にする必要がありますか (2 番目のオプションとして)、または同様の関連するコード行のブロックをラップする必要があります (最初のオプションとして) ?

try {
   Foo foo = new Foo();
   var result = SomeConnection.getBar(foo);
   return result == foo.RESULT;
} catch ( .. ) {...}

OR

Foo foo = new Foo();
try {
   SomeConnection.getBar(foo);
   return result == foo.RESULT;
} catch ( .. ) {...}
4

4 に答える 4

3

tryコードでは、ブロック内のコードの量を最小限に抑えてもパフォーマンスの問題はありません。try（最小限の）パフォーマンスへの影響はすべて、ブロック自体に出入りすることです。

編集:実装するもの (Foo実装するものをjava.lang.AutoCloseable含む) がある場合は、 「try-with-resources」ステートメントをjava.io.Closeable使用する必要があります。

try (Foo foo = new foo()) {
    var result = SomeConnection.getBar(foo);
    return result == foo.RESULT;
} catch (...) {...}

この Java 7 言語構造は、明らかにブロックに対してfooローカルであることに注意してください。try

于 2013-11-13T02:44:01.770 に答える
1

テッドの答えに加えて、例外をスローできるコンストラクターロジックがあればfoo、ブロック内に配置します。tryそれ以外は、性能面での違いはありません。私は個人的にあなたの最初のバージョンに行き、foo私がそれを使用している範囲にとどめたいと思います.ベストプラクティスに関しては、try/catch内に「最小限の」コードを入れることは大きな違いを生むとは思いません. 一方、try/catch ブロックが多すぎる (さらに悪いことに、ブロックを入れ子にする) ことは、悪い習慣です。

于 2013-11-13T02:46:40.013 に答える
0

余分なものを try/catch にラップすることは必ずしも悪いことではありませんが、一部の言語では、スローされるのは異なる例外の種類 (例: ExceptionInvalidParameter、ExceptionUnknown、...) であり、種類ごとに複数の catch ブロックを持つことができます。私は、try/catch で大量のものをラップし、予期しない例外を処理するために finally ステートメントを用意するのが好きです。

于 2013-11-13T02:44:35.920 に答える
0

プログラムは常に実行Foo foo = new Foo()されるため、そこでパフォーマンスを向上させることはできません。コードを最小限に抑えることができます。

SomeConnection.getBar(new Foo())

が定数であると仮定するfoo.RESULTと、静的な定数である可能性がありますFoo.RESULT。

于 2013-11-13T02:45:20.303 に答える