我没有尝试过这个，所以我不知道JVM是否会限制这样的东西，但也许你可以编译抛出ChuckNorrisException的代码，但在运行时提供ChuckNorrisException的类定义，它不扩展Throwable。

更新:

不管用。它生成一个验证错误:

Exception in thread "main" java.lang.VerifyError: (class: TestThrow, method: ma\
in signature: ([Ljava/lang/String;)V) Can only throw Throwable objects
Could not find the main class: TestThrow.  Program will exit.

更新2:

实际上，如果您禁用字节码验证器，您可以让它工作!(-Xverify:没有)

更新3:

对于那些在家跟随的人，这里是完整的脚本:

创建以下类:

public class ChuckNorrisException
    extends RuntimeException // <- Comment out this line on second compilation
{
    public ChuckNorrisException() { }
}

public class TestVillain {
    public static void main(String[] args) {
        try {
            throw new ChuckNorrisException();
        }
        catch(Throwable t) {
            System.out.println("Gotcha!");
        }
        finally {
            System.out.println("The end.");
        }
    }
}

编译类:

javac -cp . TestVillain.java ChuckNorrisException.java

Run:

java -cp . TestVillain
Gotcha!
The end.

注释掉"extends RuntimeException"，只重新编译ChuckNorrisException.java:

javac -cp . ChuckNorrisException.java

Run:

java -cp . TestVillain
Exception in thread "main" java.lang.VerifyError: (class: TestVillain, method: main signature: ([Ljava/lang/String;)V) Can only throw Throwable objects
Could not find the main class: TestVillain.  Program will exit.

未经验证运行:

java -Xverify:none -cp . TestVillain
The end.
Exception in thread "main"

Two fundamental problems with exception handling in Java are that it uses the type of an exception to indicate whether action should be taken based upon it, and that anything which takes action based upon an exception (i.e. "catch"es it) is presumed to resolve the underlying condition. It would be useful to have a means by which an exception object could decide which handlers should execute, and whether the handlers that have executed so far have cleaned things up enough for the present method to satisfy its exit conditions. While this could be used to make "uncatchable" exceptions, two bigger uses would be to (1) make exceptions which will only be considered handled when they're caught by code that actually knows how to deal with them, and (2) allow for sensible handling of exceptions which occur in a finally block (if a FooException during a finally block during the unwinding of a BarException, both exceptions should propagate up the call stack; both should be catchable, but unwinding should continue until both have been caught). Unfortunately, I don't think there would be any way to make existing exception-handling code work that way without breaking things.

你可以把ChuckNorris隐藏起来，也可以把他封装起来，也可以把他吞下去……

try {doChuckAction();} catch(ChuckNorrisException cne){/*做其他事情*/}

在finalize中调用System.exit(1)，并抛出来自所有其他方法的异常副本，以便程序退出。

这个主题的另一个变体是，您可以从Java代码抛出未声明的受控异常。由于它没有在方法签名中声明，所以编译器不会让您捕获异常本身，尽管您可以将其作为java.lang.Exception捕获。

这里有一个帮助类，它允许你抛出任何东西，无论是否声明:

public class SneakyThrow {
  public static RuntimeException sneak(Throwable t) {
    throw SneakyThrow.<RuntimeException> throwGivenThrowable(t);
  }

  private static <T extends Throwable> RuntimeException throwGivenThrowable(Throwable t) throws T {
    throw (T) t;
  }
}

现在扔SneakyThrow。溜(新ChuckNorrisException ());抛出ChuckNorrisException，但编译器抱怨

try {
  throw SneakyThrow.sneak(new ChuckNorrisException());
} catch (ChuckNorrisException e) {
}

如果ChuckNorrisException是一个受控异常，则捕获没有抛出的异常。

任何代码都可以捕获Throwable。所以不，无论你创建什么异常都会是Throwable的子类并且会被捕获。