你什么时候写你的异常处理程序?

时间:2009-06-20 06:12:19

标签: exception-handling

在开发过程中,您通常会实现异常处理程序吗?你在编写周围代码的同时编写它们,还是编写代码然后再回来“硬化”它?

我通常会执行后者,这样我就可以确切地看到我的代码在哪里以及如何失败,但我担心我的代码不像我可能立即编写异常处理程序那样具有弹性。

与此同时,我还不想花费大量的开发时间来找出当我还没有解决的其他实现细节时,我的代码可能失败的所有可能方式。

我很好奇其他开发者是如何做到这一点的。

更新:我只想感谢大家的回答!

10 个答案:

答案 0 :(得分:6)

我要么立即编写异常处理程序,要么允许异常向上传播。我非常喜欢我称之为“你不会回去修理它,你呢?”原理。你说你会的,但老实说,一旦你开始工作,你就不会再回去修理它了,是吗?马上做好吧!立即编写您的异常处理程序,或添加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);
}

答案 1 :(得分:1)

如果我正在调用API,那么我会查看可以抛出的异常并根据列表来决定。可抛出的异常通常属于以下类别:

  • 在我的视图中不太可能会被抛出 - 确保代码失败
  • 实际上这会被抛出 - 如果这被调用我该怎么办?
  • 确定会根据当前输入抛出此内容 - 为输入添加验证以阻止它被抛出
  • 我可以提出更相关的例外吗? - 如果异常可能被调用,那么如果我提出新的/不同的异常,其他调用代码会更清楚

总的来说,我认为在调用堆栈中捕获所有try catch块是一个很好的做法,它可以捕获一般异常(Throwable),然后很好地向用户报告 - 也许有一个接口然后发送电子邮件错误和堆栈跟踪到开发团队并询问用户评论。

答案 2 :(得分:1)

在我的异常处理程序中,我通常会引发更高级别的异常。例如,在Python中解析文件时,某些字符串,列表和字典操作可能会引发ValueError,IndexError或KeyError。这些异常通常对调用者没有帮助,因此我编写了一个异常处理程序,它引发了一个描述性的MyParseError。我在编写方法时同时执行此操作,但稍后在编写测试时,我有时会使异常消息更加冗长。

答案 3 :(得分:0)

发展期间

,时间:

  • 单元测试需要它
  • 当某些演示文稿/持久性代码需要它时

修改

在Java 有时,你必须在很早的阶段(已检查的例外)处理错误处理,而有时,这非常烦人。< / p>

答案 4 :(得分:0)

有时两者兼而有之。在某些情况下,我知道可以抛出的异常,并且我想在编写代码时处理,因此我在那里编写处理程序。其他时候我不知道所有的例外情况,并在以后通过文档,测试或两者找到它们。

答案 5 :(得分:0)

这是两者的结合。我知道有些东西会出错,比如数据库连接,配置设置,文件读/写以及功能/技术规范中的红旗。我尝试尽快设置try / catch。

随着应用程序随着时间的推移变大,我开始看到模式和趋势,无论用户如何使用应用程序,或者我和/或团队如何开发它,并根据需要添加这些尝试/捕获。

答案 6 :(得分:0)

这取决于您正在进行的项目的性质。就我而言,如果我熟悉系统的逻辑,我应该知道在编写代码之前处理异常的地点和方式。另一方面,我会编写我的东西,测试它然后编写处理程序。

答案 7 :(得分:0)

我的方法是立即解决异常处理问题,因为这不是一种漫无目的的负担,你可以高兴地推迟。

只需处理在编写代码时应用的异常,传播所有无关紧要的异常,并且只有稍后再修复以解决任何损坏的问题,才能为您节省大量的时间。

答案 8 :(得分:0)

作为一项规则,我不仅在编写代码时编写异常处理,而且我尝试编写代码以避免异常。优点是,如果我知道我需要处理异常,我记得并且如果我可以避免异常,这总是一个加号。在我使用边界条件编写代码之后,我还测试了我的代码,看看是否有任何可能的异常,我可能已经错过了。

答案 9 :(得分:0)

在编写实际代码时编写处理程序是最好的习惯,我猜是因为你很清楚可能会发生的故障,尽管你可以在发现它时添加其他故障。

处理异常可能是第一次繁琐,但在调试某些错误(即支持)时会节省大量时间。