问何时编写异常处理程序？

EN

我要么立即编写异常处理程序，要么允许异常向上传播。我是我所谓的“你不打算回去，以后再修正它，是吗？”原则。你说你会的，但老实说，一旦你把它修好了，你以后就不会回去修理它了，是吗？现在就去拿吧！立即编写异常处理程序，或添加throws子句，使其成为其他人的问题。现在就做正确的事。

但是你知道吗，有时候你做不到。不管你做什么，都不会吞下带有空异常处理程序的异常！这是邪恶的：

try {
    connection.close();
}
catch (Exception e) {
    // TODO Auto-generated code
}

我把检查过的人踢到我的队伍里。

如果您真的不知道如何处理异常，并且不能添加throws子句来向上传播异常，那么至少要做一些负责任的事情。打印堆栈跟踪，如果没有其他的话。这并不理想，但至少你没有隐藏错误。

catch (IOException exception) {
    exception.printStackTrace();
}

通过应用程序的日志系统记录它会更好，尽管你不应该养成它的习惯。处理这类事情应该是来电者的责任。

catch (IOException exception) {
    log.error(exception, "Unable to open configuration file %s.", fileName);
}

作为最后的手段，您可以通过将异常包装在throws子句中，从而完成RuntimeException子句的结束运行。至少你给了呼叫链较高的人一个处理错误的机会，这通常是正确的做法。

catch (IOException exception) {
    throw new RuntimeException(exception);
}

如果我正在调用一个API，那么我将查看可以抛出哪些异常并根据列表来决定。可以抛出的异常通常分为以下几类：

在我看来，这不太可能被抛出--确保代码失败了，nicely

• Realistic就会被抛出--如果这得到了called?

• Certain，它将根据当前的输入被抛出--向输入添加验证以阻止它被抛出，

• 可以引发一个更相关的异常吗？--如果一个异常可能会被调用，那么如果我引发了一个新的/不同的异常

，其他调用代码会更清楚吗？

一般来说，我认为最好的做法是让所有的尝试捕获块都在调用堆栈的较高的位置捕获一般异常(Throwable)，然后向用户很好地报告这些异常--可能会有一个界面，然后将错误和堆栈跟踪发送到开发团队，并向用户征求评论。

在我的异常处理程序中，我通常会引发更高级别的异常。例如，在用Python解析文件时，一些字符串、列表和dict操作可能会引发ValueError、IndexError或KeyError。这些异常通常对调用方没有帮助，所以我编写了一个异常处理程序，它会引发一个描述性的MyParseError。我在编写方法时同时这样做，但后来，在编写测试时，我有时会使异常消息更详细。