Java为何暴露Error，SE API回调为何接收Throwable而非Exception？

事实依据 #

• Java SE API 对Error类型的官方定义说明为：这类异常*“代表合理应用程序不应尝试捕获的严重问题”，同时“错误属于永远不应发生的异常条件”*。
• JLS 11.1.3节“异步异常”章节中对VirtualMachineError的定义为：“指Java虚拟机内部出现错误或资源耗尽，导致无法正常实现Java编程语言语义的场景”。

分析解读 #

• 这些官方规范不仅明确建议不要主动捕获Error，还指出一旦发生VirtualMachineError，Java语言的语义一致性就无法得到保障。之前论证Thread.stop/ThreadDeath为什么被废弃的逻辑，完全可以套用到所有VirtualMachineError场景上。由于Java默认支持类的延迟加载解析机制，LinkageError的行为逻辑也和这些场景高度相似：没有哪段正常业务代码会提前防御这类错误，一旦触发，就和ThreadDeath或VirtualMachineError一样，可能造成应用内对象状态的不可逆损坏。
• 从实际开发经验来看，上述依据已经足够说明，不存在可以可靠处理Error的通用方案。目前唯一具备可落地性的兜底方式，是配置全局的Thread.UncaughtExceptionHandler，在捕获未处理异常时调用System.exit/Runtime.halt终止虚拟机，并且在终止前尽可能记录Error日志——但要注意，日志记录操作本身也可能因为原始错误触发新的Error而失败，尤其是当原始错误是OutOfMemoryError时，这种情况会非常常见。

核心疑问 #

1. 既然Error代表永远不应发生的异常条件，规范也明确建议应用程序不要尝试捕获它，Java SE API为什么还要对外暴露Error类型，而不是完全在虚拟机内部处理这类错误、直接终止虚拟机，压根不把这类异常抛给应用层？
2. 为什么Java SE API中几乎所有的回调方法（比如java.nio.channels.CompletionHandler.failed、CompletionStage.exceptionally、Flow.Subscriber.onError）的入参，都是可以包含Error类的通用Throwable类型，而不是只接收Exception类型？本质上，这种接收Throwable的回调设计，和直接在业务代码里捕获Error没有区别——而且要实现这类回调的参数传递逻辑，代码本身就必须捕获Error，这本身就违反了Error类文档给出的使用建议。这类回调设计会强制开发者在三种并不理想的方案里做选择：
   • 继续向上传递Throwable：这只会延迟Error的处理时机，导致错误触发后仍有大量业务代码继续执行，大幅提升再次抛出其他Error的概率（如果原始错误是OutOfMemoryError，这个问题会被进一步放大）。
   • 把Error包装成普通Exception再传递：这种做法完全有害，会直接隐藏Error发生的事实，让后续上层代码完全无法通过常规类型判断识别这类致命问题。
   • 直接在回调里处理Error：除了主动终止虚拟机之外，基本不存在其他可靠的处理方式。

内容的提问来源于stack exchange，提问作者Valentin Kovalenko