我曾尝试在其他线程上寻找此问题的答案,但到目前为止,我只看到声明捕获 Throwable 不好的线程。我的问题是,是否有任何理由让您想要执行此操作,然后除了打印出堆栈跟踪之外在 catch block 中什么都不做?
我最近被带到一个项目中,任务是清理 RESTful 服务的一组现有类的错误处理。几个帮助服务类有 try/catch block ,它们只捕获 Throwable 并打印出堆栈跟踪,如下所示:
class MainService {
SubService1 s1;
SubService2 s2;
public doMainService() {
}
}
class SubService1 {
public int findSomething() {
try {
// Do Something
} catch (Throwable t) {
t.printStackTrace();
}
}
}
class SubService2 {
public int findSomethingElse() {
try {
// Do Something
} catch (Throwable t) {
t.printStackTrace();
}
}
}
是否存在这种情况可以接受的情况?如果方法抛出异常并且没有 try/catch block 会更好吗?
最佳答案
由于各种众所周知的原因,这几乎不是一个好的做法。
特别是,它不区分 checked和 unchecked异常和 errors .更重要的是,这段代码的作用之一是允许应用程序在异常处理程序之外执行,这可能会由于违反不变量而导致各种奇怪的行为。换句话说,由于捕获的异常实际上可能是任何东西,包括违反断言、编程错误、线程中断、类丢失、I/O 错误、OOM 条件甚至库和 VM 错误,程序状态实际上是无法预测的,超出了异常处理程序。
在极少数情况下,广泛的异常处理可能是有意义的。想象一个服务器处理多个独立的请求。您可能不希望由于在处理其中一个请求时遇到问题而崩溃。由于您不依赖异常处理程序之后留下的状态,您可以简单地打印堆栈跟踪并让某人调查,同时服务器继续为其他请求提供服务。
即使在这些情况下,也应该仔细考虑是否存在错误,例如VirtualMachineError
真的应该被捕获。
关于java - 为什么你会捕获 Throwable 而除了打印堆栈跟踪之外什么都不做?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9492152/