APIドキュメントには、異常な動作を示すThrowableサブクラスErrorをキャッチしないと記載されています。エラーと例外の分離は、どのサブクラスをキャッチする必要があり、どのサブクラスをキャッチするべきでないかをプログラマーに伝えることを意味しますか？それともそれ以上のものがありますか？
1528 次
2 に答える
7
一般に、これErrorは深刻な問題であり（多くの場合、プラットフォーム自体の内部で）、おそらく処理できませんでした。私がこれまでに捕まえることを気にかけたのErrorは、それを記録するためだけであり、その後、私はそれを再投げます。
これは非常に重要です。エラー（およびランタイム例外）がログに記録されないように（たとえばexecutorService.submit(Runnable)、返されたものをリッスンせずに使用してFuture）コールスタックに伝播するのは簡単だからです。
Errorsは通常次のようなものです：
- メモリ不足
- 抽象メソッドエラー（たとえば、ビルドされたライブラリとは異なるバージョンのライブラリに対して実行）
- アサーション（つまり、プログラマーが定義した不変条件、または決して起こらないはずのこと-笑！）
次に、RuntimeExceptionsは通常（常にではありませんが）プログラミングエラーを示していると言えます。
- nullをチェックしない、またはnullを渡す
- 無効な引数を渡すか、無効な状態を許可する
- コレクションを反復処理しながらコレクションを変更する
私は通常、これらについても失敗することをお勧めしますが、これは灰色の領域です。サーバーに渡す前にユーザー入力をチェックしない可能性があります-アプリをクラッシュさせる価値はほとんどありません！
チェックException済み（つまり、非ランタイム）は、コード内で発生すると合理的に予想でき、合理的に（またはおそらく）処理できるものに使用する必要があります。個人的にはチェックされた例外が好きですが、同じ方法で（つまり、複数の同一のキャッチブロックで）個別の例外タイプを処理する際に冗長性/繰り返しが発生するため、これらは煩雑になります。Scalaなどの言語は、キャッチ構文がはるかに優れていますが、チェックされた例外の概念も削除されました。
于 2010-01-27T10:46:48.023 に答える
4
はい、ここでの分析は正しいと思います。sはError、などから回復できないランタイムエラーを表しているため、sをキャッチすることは想定されていませんOutOfMemoryError。
キャッチする唯一の理由Throwableは、プログラムの正しい動作に必要のない外部のサードパーティコードを実行している場合です。そのコードを信頼できない場合は、すべてをキャッチし、予期しないものを取得した場合（Throwable）次に、そのコードを無効にして報告します。
Exceptionまた、とを区別することをお勧めしRuntimeExceptionます。
于 2010-01-27T10:42:09.343 に答える