3

例外処理とリソース管理について質問があります。意見を共有できる人がいるかどうか疑問に思っていました。一連のアクションを実行する必要があります。アプリの設定を読み取り、環境をセットアップし、作業を行い、最終的にクリーンアップします。クリーンアップには環境の破棄が含まれますが、これは、最初に正常にセットアップされた場合にのみ発生するはずです。

これが私の最初の（そして不自由な）アプローチです：

try {
 readSettings();
 setupEnvironment();
} catch (Exception ex) {
 logStackTrace(ex);
 displayError(ex);
 closeCommThreads();
 return;
}

try {
 // do stuff
} catch (Exception ex) {
 logStackTrace(ex);
 displayError(ex);
} finally {
 teardownEnvironment();
 closeCommThreads();
}

それは少し醜いように思えたので、より良い解決策を探すことにしました。私はいくつかのバックグラウンド リーディングを行い、非常に多くの記事がより大きなブロックに投票し、クリーンアップにtry/catch(しゃれ?) を使用していました。finallyだからここに私の2回目の試みがあります：

try {
 readSettings();
 setupEnvironment();
 // do stuff
} catch (Exception ex) {
 logStackTrace(ex);
 displayError(ex);
} finally {
 teardownEnvironment();
 closeCommThreads();
}

これを機能させるには、シーケンシャル カップリングを削除して、teardownEnvironment()前後にいつでも呼び出すことができるようにする必要がありましたsetupEnvironment()(編集者にとっては、より良い方法はありますか?)。これは正しいアプローチですか？セットアップする前に解体するのは少し奇妙に感じます。

編集：

もう少し明確にするために、内部に追加のチェックを含めることにより、順次結合を削除しましたteardownEnvironment- if (!isSetup()) return;.

4

3 に答える 3

2

両方の方法で意図したことを達成する場合、どちらも正しくも正しくもありません。

私の意見では、2 番目のアプローチ (大きな try/catch/finally ブロック) は、メソッド本体のどこかにある catch ブロックに "隠された" return ステートメントがないため、読みやすくなっています。

さらに、メソッド間の相互依存性 (ティアダウン、セットアップ) を取り除くことは、一般的に良い方法だと思います (たとえば、これらのメソッドを個別に単体テストできます)。何も設定されていない場合は、ティアダウンを終了してください - 変に感じる必要はありません :)

于 2010-11-26T11:44:40.410 に答える
2

このfinallyアプローチは、例外がスローされる前に、使用されているリソースをクローズ/逆参照できる (およびガベージ コレクションの準備ができている) ことを保証するために使用されます。これは、例外の安全性を促進するためのものです。

ここで説明したことは、Dispose パターンと呼ばれます。基本的に、Java GC の自動性質により、ランタイム環境のリソースのクリーンアップを行っています。

tearDownEnvironment()JVM GC が作動する前にすべてのリソースを閉じて、環境を効果的にクリーンアップしているため、2 番目のアプローチは正しいです (これは Dispose パターンです) 。

追加情報:リソースの取得は初期化でしょう か?

于 2010-11-26T11:45:49.800 に答える
1

通常、あなたteardownEnvironment()はチェックします

isEnvironmentSetCorrectly()またはif(environment != null)または類似のもの

取り壊しを始める前に。

したがって、正しく実行すれば発生しないため、「少し奇妙に感じる」必要はありません。

于 2010-11-26T11:37:14.367 に答える