0

例外をスローする行為が代わりに別の例外をスローすることは可能ですか？

例外をスローするには、（オプションで）新しいオブジェクトを割り当て、そのコンストラクターを呼び出す必要があります（暗黙的にfillinstacktraceを呼び出します）。場合によっては、addSupressedも呼び出されるように聞こえます。では、十分なメモリがない場合はどうなりますか？JVMは、組み込みの例外を事前に割り当てる必要がありますか？たとえば、（1/0）はArithmeticExceptionの代わりにOutOfMemoryErrorをスローしますか？

また、コンストラクターはメソッド呼び出しであるため、他の例外を自由にスローできます。この場合はどうなりますか？組み込みの例外がスローされることはありますか？明示的にスローしなくても、StackOverflowErrorが発生する可能性があります。

4

3 に答える 3

5 
public class MyStupidException extends Exception {
  public MyStupidException() {
    throw new RuntimeException("whoooo");
  }
}
public static void main(String... args) throws Exception {
  throw new MyStupidException();
}

プリント:

スレッド「メイン」での例外 java.lang.RuntimeException: whoooo

あ、はい ：-）

組み込みの例外の場合、問題が発生する可能性があることが多数あります。仕様では、JVM が例外割り当ての成功を保証する必要があるとは思わないためOutOfMemoryError、明確な可能性のように聞こえます。クラスの読み込みエラーなど、発生する可能性がある、よりあいまいな問題もあります。java.lang.Exceptionまた、誰かが変更を加えて例外やエラーをスローさせるという、実に難解な状況に陥ることもあります。

したがって、私の意見では、例外処理自体が非常にまれなケースで例外を引き起こす可能性があることを期待/計画する必要があります。

于 2012-08-13T18:14:51.830 に答える
4

ArthimeticExceptionオブジェクトを作成するための十分なスペースがない場合OutofMemoryError、JVM にはプロセスを終了する以外に先に進む方法がないため、オブジェクトは処理されます。

于 2012-08-13T18:14:26.777 に答える
1

得られる

Error err = null;
throw err; // triggers a NPE.

また

// use up almost all the memory
throw new RuntimeException(); // throws OutOfMemoryError instead.
于 2012-08-13T18:27:24.973 に答える