Question

考虑一个在其体内抛出一些异常的方法（）。请考虑以下情况：
场景1：

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

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

还要考虑这个：
场景2：

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

为什么不允许出现情景2这样的情况？即为什么强制应该在方法中处理异常？

Answer 1

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

void method() throws Exception{
}

Answer 2

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

在第一个场景中，被调用的方法本身处理异常 - 因此调用方法中不需要try-catch。

第二种情况是有效的 - 但仅当method()包含throws声明以指示必须在其他地方处理异常时才会生效。

void method() throws Exception
{
}

Answer 3

允许！使用如下

public void method() throws ClassNotFoundException {

捕获ClassNotFoundException。（在大多数情况下，你不应该像其他海报一样简单地抛出Exception）

是否在内部或外部聊天是软件设计。没有经验法则。我的经验是，捕获外部会导致代码更简单，可以更好地进行单元测试。

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

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

也有意义

Answer 4

如果使用senario-2处理异常，则无法将异常映射到实际异常。即你不能按照块中的代码说明它。因此，请处理现场本身的异常，以便您可以具体解释异常发生的原因。

Answer 5

如上所述，我们的想法是尽早提早出现。总的来说，您希望通过简单地使逻辑“流动”来最小化您抛出的异常。但总是存在处理或过多混淆代码的情况，因此值得确保用户理解使用某些方法的风险并相应地处理它们。

Answer 6

TL; DR：永远不要陷阱InterruptedException，除非你真的想要。它几乎总是需要抛出。

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

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