キャッチブロック内でスローされた例外-再びキャッチされますか？

これはプログラミング101の質問のように思えるかもしれませんが、私は答えを知っていると思っていましたが、今度は自分自身を再確認する必要があることに気づきました。以下のこのコードでは、最初のcatchブロックでスローされた例外は、以下の一般的なException catchブロックによってキャッチされますか？

try {
  // Do something
} catch(IOException e) {
  throw new ApplicationException("Problem connecting to server");
} catch(Exception e) {
  // Will the ApplicationException be caught here?
}

私はいつも答えはノーだと思っていましたが、今これによって引き起こされる可能性のある奇妙な行動があります。答えはおそらくほとんどの言語で同じですが、私はJavaで作業しています。

いいえ、新しいものthrowはtry直接ブロックされていません。

いいえ。確認は非常に簡単です。

public class Catch {
    public static void main(String[] args) {
        try {
            throw new java.io.IOException();
        } catch (java.io.IOException exc) {
            System.err.println("In catch IOException: "+exc.getClass());
            throw new RuntimeException();
        } catch (Exception exc) {
            System.err.println("In catch Exception: "+exc.getClass());
        } finally {
            System.err.println("In finally");
        }
    }
}

印刷する必要があります：

キャッチIOException：クラスjava.io.IOException
いよいよ
スレッド「メイン」の例外java.lang.RuntimeException
        Catch.main（Catch.java:8）で

技術的には、コンパイラのバグ、実装に依存する、不特定の動作などが考えられます。ただし、JLSはかなりうまく機能しており、コンパイラーはこの種の単純なことには十分対応できます（ジェネリックのコーナーケースは別の問題かもしれません）。

また、2つのcatchブロックを入れ替えても、コンパイルされません。2番目の漁獲量は完全に到達不可能です。

catchブロックが実行された場合でも、finallyブロックは常に実行されることに注意してください（無限ループ、ツールインターフェイスを介した接続、スレッドの強制終了、バイトコードの書き換えなどのばかげた場合を除く）。

Java言語仕様はセクション14.19.1で述べています：

値Vがスローされたためにtryブロックの実行が突然完了した場合は、選択肢があります。

• Vの実行時の型がtryステートメントのいずれかのcatch句のパラメーターに割り当て可能な場合、最初（左端）のそのようなcatch句が選択されます。値Vが選択されたcatch節のパラメーターに割り当てられ、そのcatch節のBlockが実行されます。そのブロックが正常に完了すると、tryステートメントは正常に完了します。そのブロックが何らかの理由で突然完了した場合、tryステートメントは同じ理由で突然完了します。

リファレンス：http : //java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#24134

言い換えると、例外を処理できる最初の囲んでいるキャッチが実行され、そのキャッチから例外がスローされた場合、それは元の試行の他のどのキャッチのスコープにも含まれないため、処理しようとしません。

関連して混乱することの1つは、try- [catch] -finally構造では、finallyブロックが例外をスローする可能性があり、その場合、tryまたはcatchブロックによってスローされた例外はすべて失われることです。初めて見ると混乱するかもしれません。

catchブロックから例外をスローする場合は、メソッド/クラスなどに通知する必要があります。上記の例外をスローする必要があること。そのようです：

public void doStuff() throws MyException {
    try {
        //Stuff
    } catch(StuffException e) {
        throw new MyException();
    }
}

そして今、あなたのコンパイラはあなたに怒鳴りません:)

いいえ-Chris Jester-Youngが言ったように、階層内の次のtry-catchまでスローされます。

上で述べたよう
に、何が起こっているのかがわからない場合、デバッガで問題を再現できない場合は、新しい例外を再スローする前にトレースを追加できます（古き良きシステム悪いことに.out.println、それ以外はlog4jのような優れたログシステム。

2番目のcatchブロックではキャッチされません。各例外は、tryブロック内でのみキャッチされます。ただし、試行を入れ子にすることもできます（一般的には、これは良いことではありません）。

try {
    doSomething();
} catch (IOException) {
   try {
       doSomething();
   } catch (IOException e) {
       throw new ApplicationException("Failed twice at doSomething" +
       e.toString());
   }          
} catch (Exception e) {
}

いいえ、すべてのキャッチが同じtryブロックを参照しているため、catchブロック内からのスローは、（おそらくこれを呼び出したメソッド内の）囲んでいるtryブロックによってキャッチされます。

古い投稿ですが、「e」変数は一意である必要があります：

try {
  // Do something
} catch(IOException ioE) {
  throw new ApplicationException("Problem connecting to server");
} catch(Exception e) {
  // Will the ApplicationException be caught here?
}