Java 重写的方法不引发任何异常时的异常处理

缩写：当被重写的方法不抛出异常时，如何抛出异常（或进行良好、干净的异常处理；或至少脏兮兮地强制执行停止）

上下文：我们有一个专有软件的许可证，该软件可以使用Java“宏”进行自动化。用户定义的宏必须采用以下形式：

public class MyMacro extends SoftwareMacro {
    public void execute() {
        // user code goes here
    }
}

i、 e.一个扩展

SoftwareMacro

的类，它具有一个名为

execute

的方法，该方法覆盖基类“

execute

。这个覆盖的

execute

的内容是。。。好。。。在“播放”宏时执行

但是被重写的

execute

方法显然不会抛出任何异常

execute() in com.mycompany.mypackage.MyMacro cannot implement execute() in 
somesoftware.base.SoftwareMacro
overridden method does not throw java.lang.Exception

也许这很幼稚，但在开发过程中，我通常喜欢将适当的异常类型冒泡到顶部并强制执行停止，这样我就可以看到它们并继续调试。这显然不是一个选择

我应该转而抛出

RuntimeException

？（因为不需要指定

RuntimeException

），这感觉有点草率，并且是基类方法contracy的“精神违反”

---

不，我不能更改被重写的

execute

方法的源代码

看起来其目的是让每个

SoftwareMacro

都执行自己的错误处理。如果需要，在整个

execute（）

方法周围使用一个大的

try

，但不要让任何异常逃逸。在execute方法内部执行您需要执行的任何清理，如果用户提供了执行方法，则可能会为用户打印一条错误消息

---

您应该检查它们提供的所有API——也许您应该使用一个错误报告工具。

只要执行的

代码没有吸收异常，如果遇到异常，它仍然会抛出异常。如果抛出的异常类型是
RuntimeException
或
RuntimeException
的子类，则不需要显式声明它们，这主要是因为编译器不强制执行它们的声明，因为（顾名思义）它们只发生在运行时，不一定在编译时预测

但是，如果
execute
方法（您说过不能修改）吸收了异常，并且没有通过日志条目、返回值或某种
RuntimeException
指示异常，我认为您运气不好

我同意Ernest的观点，其目的似乎是
execute
方法执行其自身的所有异常处理

注意：被重写的方法签名在抛出异常时不需要精确匹配，只需要名称、返回类型以及变量的列表和类型。
这完全取决于“宏播放器”在遇到运行时异常时的操作，以及您希望发生的操作

如果它根本无法处理，但您不在乎，则抛出RuntimeException

如果它正确处理它们，则抛出RuntimeException

如果它不能正确地处理它们，并且您不希望它失败得很惨，那么捕获您的execute方法中可能发生的异常，并按照您认为最好的方式处理它们：显示错误对话框，输出错误消息，在日志中记录一些错误…
“应该”意味着有正确的答案，我没有什么能满足你的需要

如果系统能够容忍运行时异常，并且满足您的需求，为什么不呢

这并不是说你有选择的余地，因为你不能抛出一个选中的异常

（对我来说，检查异常似乎是一个失败的实验，尽管我理解其动机。）
干净的方法是使用一个集中的“异常”处理程序，它将检测重写方法内部异常的“引发”，并停止应用程序执行。实用的方法是抛出一个RuntimeException。@DaveHowes-是的，你误读了，对不起。Java要求重写方法的异常规范是被重写方法异常规范的适当子集；空集当然是一个适当的子集。你不需要抛出与你的超类相同的异常。好吧，我正在尝试采用良好的习惯和良好的实践，这就是“应该”所暗示的。我在寻找比满足眼前需要更具远见的东西。@Jean-FrançoisCorbett好习惯是。。。很好，但只有当你的工作满足你的需要时。显然，作者认为所有的错误处理都应该在宏中完成，这可能是适当的——这取决于上下文。但是，通过不提供任何特定于框架的异常签名，他们已经将您锁定在了其中。想想厄内斯特所说的，是否有一个报告错误的框架机制？此外，即使系统实际上没有停止，您仍然可以记录异常以供检查。不，不完全匹配，但重写方法仅限于抛出被重写方法的指定异常的子集（而不是超集）。