重写方法不抛出任何异常时的异常处理
简短形式：当重写的方法不抛出异常时，如何抛出异常（或者进行良好、干净的异常处理；或者至少强制停止执行）？
上下文：我们拥有一款专有软件的许可证，该软件可以使用 Java“宏”实现自动化。用户定义的宏必须采用以下形式：
public class MyMacro extends SoftwareMacro {
public void execute() {
// user code goes here
}
}
即扩展 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 ）这感觉有点草率，而且是对基类方法契约的“精神上的侵犯”。
PS 不，我无法更改重写的 execute 方法的源代码。
Short form: How do you throw exceptions (or do nice, clean exception handling; or at least dirtily force execution to stop) when the overridden method doesn't throw exceptions?
Context: We have a license for a piece of proprietary software that can be automated using Java "macros". A user-defined macro must be of this form:
public class MyMacro extends SoftwareMacro {
public void execute() {
// user code goes here
}
}
i.e. a class that extents SoftwareMacro and that has a method called execute that overrides the base class' execute. The contents of this overriding execute are what gets... well... executed when the macro is "played".
But the overridden execute method apparently does not throw any exceptions.
execute() in com.mycompany.mypackage.MyMacro cannot implement execute() in
somesoftware.base.SoftwareMacro
overridden method does not throw java.lang.Exception
Maybe this is naïve, but while developing I usually like to have the appropriate exception type bubble up to the top and force execution to stop, so that I can see them and go on to debug. This is apparently not an option here.
Should I resort to throwing RuntimeException instead? (since RuntimeException does not need to be specified) That feels a bit sloppy, and a "violation in spirit" of the base class method contracy.
P.S. No, I can't change the source code of the overriden execute method.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
看起来意图是每个
SoftwareMacro执行自己的所有错误处理。如果需要，请在整个execute()方法周围使用大的try，但不要让任何异常逃脱。在执行方法中执行您需要执行的任何清理操作，并且可能为用户打印一条错误消息（如果他们提供了执行此操作的方法）。您应该检查它们提供的所有 API——也许您应该使用一个错误报告工具。
Looks like the intent is that each
SoftwareMacrodo all its own error handling. Use a bigtryaround your wholeexecute()method if need be, but don't let any exceptions escape. Do whatever cleanup you need to do inside your execute method, and possibly print an error message for the user, if they provide a way to do that.You should examine all the APIs they provide -- perhaps there's an error reporting facility you're supposed to use.
这完全取决于“宏播放器”在遇到运行时异常时会做什么，以及您希望发生什么。
如果它根本不处理它，但你不在乎，则抛出 RuntimeException。
如果正确处理它们，则抛出 RuntimeException。
如果它不能正确处理它们，并且您不希望它惨败，那么捕获您的执行方法中可能发生的异常，并按照您认为最好的方式处理它们：显示错误对话框，输出错误消息，在日志中记录一些错误...
It all depends on what the "Macro player" does if it encounters a runtime exception, and on what you want to happen.
If it doesn't handle it at all, but you don't care, throw a RuntimeException.
If it handles them properly, throw a RuntimeException.
If it doesn't handle them properly, and you don't want it to fail miserably, then catch the exceptions that might happen in your execute method, and handle them as you feel is the best: show an error dialog box, output an error message, log some error in the logs...
“应该”意味着有一个正确的答案，但 IMO 并不能满足您的需求。
如果系统可以容忍运行时异常，并且满足您的需求，为什么不呢？
并不是说您有选择，因为您不能抛出已检查的异常。
（检查异常对我来说似乎是一个失败的实验，尽管我理解其动机。）
"Should" implies there's a right answer, which IMO there isn't do what meets your needs.
If the system can tolerate a runtime exception, and it meets your needs, why not?
Not that you have a choice, since you can't throw a checked exception.
(Checked exceptions seem like a failed experiment to me, although I understand the motivation.)
只要
execute代码不吸收异常，如果遇到异常，它仍然会抛出异常。如果抛出的异常类型是 RuntimeException 或 RuntimeException 的子类，则不需要显式声明它们，主要是因为编译器不会强制执行它们的声明，因为（顾名思义）它们仅在运行时发生，并且不一定在编译时进行预测。但是，如果您说过无法修改的
execute方法会吸收异常，并且不会通过日志条目、返回值或某种< code>RuntimeException 我认为你运气不好。我同意 Ernest 的观点，似乎其意图是
execute方法执行其自己的所有异常处理。注意：重写的方法签名不需要与它们抛出的异常完全匹配 - 只需名称、返回类型以及列表和类型即可。变量的类型。
So long as the
executecode doesn't absorb the exception, it will still throw it if one is encountered. If the kind of exceptions thrown are eitherRuntimeExceptionor sub-classes ofRuntimeExceptionthey don't need to be explicitly declared, mostly because the compiler doesn't enforce their declaration since (as the name implies) they only happen at runtime, and cannot necessarily be predicted at compile time.If, however, the
executemethod, which you've said you can't modify, absorbs the exception, and doesn't indicate that exception via a log entry, return value, or some kind ofRuntimeExceptionI think you're out of luck.I would agree with Ernest that it appears that the intent is that the
executemethod do all its own exception handling.NOTE: Overridden method signatures don't need to match exactly when it comes to the exceptions they throw - just the name, return type, and list & type of variables.