4

サブクラスtryをスローするブロックがある場合、後続のブロックでそれをキャッチできますか? 具体的には：RuntimExceptioncatchException

public class MyAppException extends RuntimeException {
    // ....
}

// In some other part of the code:
try {
    // Executing this results with doSomething() throwing a MyAppException.
    int x = doSomething();
} catch(Exception exc) {
    // Does the thrown MyAppException get caught here?
}

aが拡張するため、私の考えはyesです。ただし、このように動作しない製品コードがいくつかあります。明らかに、答えがノーなら、それが私の答えです。それ以外の場合は、掘り下げて、コードが壊れている理由を確認する必要があります。前もって感謝します！RuntimeExceptionException

4

7 に答える 7

11

RuntimeExceptionから派生しExceptionているので、引っ掛かります。

そうは言っても、やらないでください！ランタイム例外は、キャッチするのではなく、防止する必要があります。

于 2012-10-18T09:23:29.750 に答える
8

はい。キャッチしますが、キャッチブロックで発生しRuntimeExceptionた場合は再度キャッチする必要があります。Exception

ローカル展開を行い、コードをデバッグすることをお勧めします。

于 2012-10-18T09:22:56.137 に答える
5

catch（Exception）がRuntimeExceptionをキャッチしていない場合、アプリケーションは思ったとおりに動作していません。

try {
    throw new RuntimeException();
} catch (Exception e) {
    System.out.println("Caught "+e);
}

プリント

Caught java.lang.RuntimeException
于 2012-10-18T09:24:31.280 に答える
3

はい。RuntimeExceptionsをキャッチすることが可能です。Throwableのすべてのサブクラスをキャッチできます。

于 2012-10-18T09:25:06.380 に答える
3

はい、RuntimeExceptionをキャッチできます...しかし、それは良いアプローチではないと思います。キャッチした場合は、適切に管理する必要があります。そうでなければ、結果はあなたの手に負えません。最善の方法は、 JVM に任せることです。JVM がそれを処理します。

于 2012-10-18T11:39:11.627 に答える
1

はい、あなたの考えは正しいです。「コードを書くだけ」に対する答えを知る最善の方法だと思います。コードに答えを教えてください。次の簡単なサンプル コードを確認できます。

    package own;

public class MyExceptionTest {

    public void testRuntimeException (){
        throw new MyException();
    }

    public static void main(String[] args) {
        try{
            new MyExceptionTest().testRuntimeException();
        }catch(Exception e){
            System.out.println(e.getClass().getName());
        }
    }
}    

class MyException extends RuntimeException{
    public MyException(){
        super();
    }
}
于 2012-10-18T09:36:20.167 に答える
-4

私は IT のプロジェクト マネージャーであり、開発者と何度も同じ議論をしてきましたが、彼らはまったく気にしません。ネットを徘徊していると、ほとんどの人がRuntimExceptionをキャッチしてスローすることを提唱しています...それを見るたびに、私は10年間の経験の無能さに信じられないほど激怒します....

ルール 1:

RuntimeException をキャッチしなかった場合は、Program で runtimeException をスローしないでください。

ルール 2:

ソフトウェアとは関係のないものを実際にインポートするために、Runtimeexception のみをキャッチします。たとえば、オペレーションの緊急シフトにメールを送信し、例外を記録し、サーバーを再起動します。

これは、優れたソフトウェアでは、ログファイルにスタック トレースがないためです。コーディングを開始するのが面倒な場合は、次のようにします。

新しいクラス DevelopmentException 拡張例外を作成します。次に、先に進んでコードを記述し、最初に例外をキャッチします。次に、それを独自の開発例外として再スローします。それをキャッチするメソッドで、ログに記録します。

今: 非常に個人的な DevelopmentException の毎日の grep。見つかった場合は、まだやるべきことがあるということです。コードに移動し、例外がどこから来たのかを確認し、事前にキャッチします。

理想的には、プログラムのこの部分で DevelopmentException が再び表示されることはありません。ソフトウェアに残っているスタックトレースが 0 になり、例外処理が完了するまで繰り返します。

実行時例外のスローとキャッチに関する最大の問題は、コンパイルがそれを無視することです。つまり、同僚の 1 人が予約インターフェイスを作成し、値が欠落しているときに RuntimeException をスローした場合 (そうです、実際にそうです)... ...コンパイラは、runtimeexception が存在する可能性があることを表示しません。現在、それをキャッチしないと、プログラムはログなしでシャットダウンする可能性があります。

なぜ RuntimeException と呼ばれるのですか? 多くの人はこれをプログラムのランタイム中のエラーと間違えますが、実際には「Java ランタイム環境を停止する必要があるほど破壊的な例外」を意味します。つまり、OutOfMemory、BrokenRam、JRE の FaultyImplementation など...基本的には、PC がクラッシュしているため、プログラムを実行できません....

ちょうど私の2セント。同じことを経験した人はいますか？

PS:スタックトレースの継続的な削除について:

例外を見つけたら、NullpointerException などでキャッチしてみてください。Nullpointerexception が表示されたら、コードに移動してスタックトレースを削除し、log.WARN(NullpointerOccured) を作成して、再試行するプログラムを作成します...

Stacktrace が表示されなくなるまで繰り返すのが理想的です。スタックトレースが表示されない場合は、問題が発生する可能性があるすべてが処理されたことを意味します(もちろん、RuntimeException を除く)。

于 2015-03-19T22:34:57.543 に答える