12

たとえば、一般的なアイテムをディスパッチし、エラーから回復する必要があるディスパッチャー キューを作成する場合など、Throwable をキャッチする必要がある場合があります (ディスパッチャーは、キャッチされたすべての例外をログに記録しますが、黙って実行し、他のアイテムで実行を継続します)。

私が考えることができるベスト プラクティスの 1 つは、例外が InterruptedException の場合は常に再スローすることです。

別の提案（回答ではなくコメントからのもの）は、常にThreadDeathを再スローすることです

他のベストプラクティスはありますか?

4

4 に答える 4

12

おそらく最も重要なのは、チェックされた例外を決して飲み込まないことです。これは、これをしないことを意味します：

try {
  ...
} catch (IOException e) {
}

それがあなたの意図でない限り。チェック例外を飲み込んでしまうことがあります。それは、チェック例外をどう処理したらよいかわからない、または「throws Exception」句でインターフェイスを汚染したくない (またはできない) ためです。

どうすればよいかわからない場合は、次のようにします。

try {
  ...
} catch (IOException e) {
  throw new RuntimeException(e);
}

もう 1 つ頭に浮かぶのは、例外を確実に処理することです。ファイルの読み取りは次のようになります。

FileInputStream in = null;
try {
  in = new FileInputStream(new File("..."));;
  // do stuff
} catch (IOException e) {
  // deal with it appropriately
} finally {
  if (in != null) try { in.close(); } catch (IOException e) { /* swallow this one */ }
}
于 2009-07-08T11:38:29.837 に答える
2

何に取り組んでいるかによります。

他の人が使用する API を開発している場合は、例外を再スローするか、独自のカスタム例外にラップしてスローすることをお勧めします。

一方、エンドユーザー アプリケーションを開発している場合は、この例外を処理し、必要なことを行う必要があります。

于 2009-07-08T11:39:34.500 に答える
2

OutOfMemoryError (またはおそらくそのスーパークラス VirtualMachineError) はどうですか? そんなに深刻なことをした後、あなたができることがたくさんあるとは想像できません。

于 2011-03-17T10:36:06.100 に答える
1

ディスパッチャ キューを作成している場合は、例外が戻ってくるまでに、ログに記録する以外に何をしても意味がありません。Swing イベント キューには、基本的にそのタイプの動作があります。

または、 ThreadGroupと同様に、「キャッチされていない例外ハンドラー」のフックを提供することもできます。ハンドラーには時間がかかり、最終的にディスパッチャーが遅れる可能性があることに注意してください。

InterruptedException に関する限り、それを気にするのは、処理を停止する必要があるかどうかを確認するために何らかの外部状態をチェックする必要があるディスパッチ ループだけです。

于 2009-07-08T11:51:10.387 に答える