-5

考虑一个在其主体中引发异常的 method()。考虑以下场景：
场景 1：

{
  //..
  // ..
  method();    //Exception handled inside the method
  //..
  //..
}

在这种情况下，应该在 method() 本身内处理异常。

还要考虑这一点：
场景 2：

{
   //..
   //..
   try{
      method();   //Exception not handled with-in the method
      }
    catch(){}
   //..
   // ..
}

为什么不允许出现场景 2 之类的情况？即为什么强制在方法内处理异常？

4

6 回答 6

2

您可以在您的方法中添加throws子句并使其抛出一个exception可以处理的 ，如情况 2中所述。所以它是允许的，像这样： -

void method() throws Exception{
}
于 2013-02-28T11:20:50.947 回答
1

这两种情况都是允许的。Java 施加的限制（如果这是正确的术语）是必须在某处处理异常。

在第一种情况下，被调用的方法自己处理异常——因此调用方法中不需要 try-catch。

第二种情况是有效的——但前提是method()包含throws声明以指示必须在其他地方处理异常。

void method() throws Exception
{
}
于 2013-02-28T11:26:03.853 回答
1

这是允许的！使用如下

public void method() throws ClassNotFoundException {

捕获 ClassNotFoundException。（在大多数情况下，您不应该Exception像其他简化的海报一样扔裸露的 ）

无论是在里面聊天还是在外面聊天都是软件设计。没有经验法则。我的经验是，捕捉外部导致代码不那么复杂，可以更好地进行单元测试。

寻找设计模式“最后一道防线”：这意味着在你最顶级的类中，例如在 main() 中有一个 catch (Exception ex) {

当没有其他方法捕获它时捕获它。在这种情况下，您可以记录异常并（尝试）安全地关闭系统。这是最后一道防线。注意： spmetimes 也有意义catch(Throweable th)，

于 2013-02-28T11:29:21.580 回答
0

TL；DR：除非您真的有意，否则切勿捕获InterruptedException 。它几乎总是需要被抛出。

这个伟大的问题实际上是一个非常重要的设计决策。做到这一点很困难，而在整个团队中做到这一点则更加困难。问题的答案在于您的实施。错误是否需要立即显示给用户？您有从故障中恢复的辅助方法吗？异常是致命事件吗？

请帮自己一个忙，永远不要编写空的异常处理程序。当出现问题时，您会很高兴在其中放入 log.debug 语句。除此之外：了解每个异常的含义并以最优雅的方式对其做出响应。

于 2013-02-28T11:25:58.553 回答
0

如果您使用 senario-2 处理异常，则无法将异常映射到实际异常。即您不能按照块中的代码说明它。所以请针对现场自身处理异常，以便具体说明为什么会发生异常。

于 2013-02-28T11:21:53.633 回答
0

如上所述，我们的想法是早投晚收。总体而言，您希望通过简单地使逻辑“流动”来最小化抛出的异常。但是总有一些情况很难处理，或者代码混淆太多，所以确保用户了解使用某些方法的风险并相应地处理它们是值得的。

于 2013-02-28T11:23:04.830 回答