45

与えられた:ThrowableはExceptionのスーパークラスです。

独自の「例外」の記述に関するテキストを読むと、ブロックで使用されている例とThrowable、catchブロックで使用されている他のテキストが表示new Exception() されcatchます。それぞれをいつ使用する必要があるかについての説明はまだ見ていません。

私の質問はこれです、いつ使用する必要Throwableがあり、いつ使用する必要new Exception()がありますか?

catchorelseブロック 内で次のいずれかを使用します。

throw throwable;

また 

throw new Exception();
4

12 に答える 12

42

常にスローしますException(決して a ではありませんThrowable)。通常、どちらもキャッチしませんThrowableが、キャッチできます。Throwable はExceptionandのスーパークラスErrorなので、 s だけでなく s もThrowableキャッチしたい場合は catchします。それがポイントです。問題は、s は通常、通常のアプリケーションではキャッチできないものであり、キャッチしてはならないものであるため、使用する特別な理由がない限り使用してください。ExceptionErrorErrorExceptionThrowable

于 2009-01-31T04:20:50.883 に答える
15

（コメントから）これを引き起こした問題は、コレクションが構築されない場合、同僚が構築しているコードの一部に「例外」を渡す必要があるということです。

その場合、チェックされた例外をスローすることをお勧めします。、その適切な既存のサブクラス（およびチェックされていないそのサブクラスをException除く）、またはのカスタムサブクラス（例： " "）をスローできます。Java例外について理解するには、例外に関するJavaチュートリアルを参照してください。RuntimeExceptionExceptionCollectionBuildException

于 2009-01-31T05:05:47.640 に答える
9

例外を実際にキャッチして、「新しい例外」のように一般的な新しい例外をスローするべきではありません。

代わりに、例外をバブルアップしたい場合は、次のようにします。

try {
    // Do some stuff here
}
catch (DivideByZeroException e) {
    System.out.println("Can't divide by Zero!"); 
} 
catch (IndexOutOfRangeException e) { 
    // catch the exception 
    System.out.println("No matching element found.");
}
catch (Throwable e) {
    throw e; // rethrow the exception/error that occurred
}

元の例外の原因を突き止めるのに十分なコンテキストを提供する有用なカスタム例外を発生させない限り、例外をキャッチして、コードブロックに発生した例外の代わりに新しい例外をスローするのは良い習慣ではないと私は信じています.

于 2009-01-31T04:24:22.497 に答える
5

Throwableコード内で単語を表示する必要があるのは、次の 2 つの場所だけです。

public static void main(String args[])
{
     try
     {
         // Do some stuff
     }
     catch(Throwable t)
     {

     }
 }

と

public class SomeServlet extends HttpServlet
{
      public void doPost(HttpRequest request, HttpResponse response)
      {
         try
         {
             // Do some stuff
         }
         catch (Throwable t)
         {
              // Log
         }
      }
 }
于 2011-04-12T22:00:21.040 に答える
1

throw new Exception();は、catch ブロックでは絶対に行うべきではありませんが、メソッドの API に準拠するために、new SomeException(throwable);代わりに throw (完全なスタック トレースを保持する)を行う必要があるか、または行う必要がある場合があります。メソッドの句に追加したくない をスローする可能性のあるコードを再呼び出しします。throw throwable;SomeExceptionIOExceptionthrows

おそらく最も一般的なケースは、句をまったくnew RuntimeException(throwable);持たないようにすることです。throwsチェック例外を使用する必要があるため、これは恐ろしい悪用であると多くの人が言うでしょう。IMOは間違っており、チェックされた例外はJava言語設計の間違いであり、醜くて保守できないコードになります。

于 2009-01-31T09:45:53.923 に答える
1

Throwable はクラスではなくインターフェイスです。2 つのクラスは、Throwable、Exception、および Error を拡張します。

ルールは次のとおりです。例外をキャッチするときは、できるだけ具体的にします。つまり、たとえば、Throwable ではなく Exception をキャッチし、Exception ではなく IOException をキャッチします。

エラーをキャッチしないでください - エラーはバグです。代わりにコードを修正してください。

絶対にすべてをキャッチする必要がある場合は、「catch Throwable」を使用しますが、これは悪い形式です。

于 2009-01-31T04:20:58.993 に答える
0

通常、Throwable を投げたりキャッチしたりしません。特に、( Error() を拡張する) JVM エラーは、奇妙なシステム レベルの作業を行っていない限り、ユーザー コードによってキャッチされることを意図していません。

「Throwable」を言語アーティファクトとして扱います。「例外」クラスは、プログラマーがコード ブロックを「例外的に」終了させたい場合 (正常に終了しないか、値を返すことによって) 使用することを意図しているため、この名前が付けられています。

これには、通常のエラー状況 (「通常」とは、JVM エラーとは対照的に意味します) と、制御メカニズムとして例外を使用している場所の両方が含まれます。

于 2009-02-01T07:29:41.343 に答える
0

javaが出た当初に聞いた話では、Throwableは例外以外の場合の制御移譲にも使えるのではないか、というのがセオリーでした。ただし、そのように使用されているのを見たことはありません (そして、それはおそらく非常に良いことです)。

したがって、例外をキャッチするだけです (または、よりきめ細かい例外をキャッチすることをお勧めします)。

于 2009-01-31T04:30:11.177 に答える
0

Throwable は、プログラムのコンテナーまたはメイン ループによってのみキャッチされることを意図しています。ほとんどの場合、エラーなどの例外をキャッチしても、プログラムに多くの機能が追加されることはありません。結局のところ、VirtualError やその他のエラーがスローされた場合に何ができるでしょうか。ログと続行以外はあまりありません。

于 2009-01-31T04:33:29.483 に答える
0

結局、すべての例外は問題です...エラーはバグであり、何の意味もありません。

エラーはバグではありません。ホスト VM で発生している問題です (OutOfMemoryError など)。例外は、現在の操作が失敗したことを通知し、おそらく何らかの診断を提供するために使用できる手段です。

于 2009-02-01T02:47:45.717 に答える
0

例外を「戻り値の型」として使用しないでください...

スローしている条件が一般的である場合、その条件を呼び出しルーチンに返すために膨大な量のリソースを費やしています。例外の作成にはコストがかかります。

ID割り当てなどの「ネガティブ」として例外をスローするタイトループのケースを見てきました.このルーチンはCPU時間の約99％を占めていました..代わりに文書化された戻り定数に変更すると、これは25％に低下しました。

于 2010-03-04T16:05:33.667 に答える