Exception handling 我们是否应该总是捕捉异常，将其包装并传递给其他人？

我读过这样一种方法：

public void doSomething throws MyException{
    ...
    try {
         doSomthingElse();
    } catch (MyException e){
         log.errer(e.getMessage());
         throw new MyException(e.getMessage(),e);
    }
    ...
}

但我更喜欢：

public void doSomething throws MyException{
     ...
     doSomthingElse();         
     ...
}

---

有人知道第一种方法的原因吗？只有一种类型的异常，并且它不是在这个方法中处理的，是否有任何理由捕获它，在没有新信息的情况下包装它，然后传递它？为什么不用第二种方式编写它呢？谢谢

除了想记录异常或在“本地”对其执行其他操作之外，我看不出任何原因

您可能希望捕获并记录发生的特定错误，以便更好地进行记录，但随后通过抛出新异常在更高级别上进行处理。

在您的示例中使用此“包装器”的原因可能是永远不会错过异常，至少要记录它。我认为在

catch

块中没有其他意义，因为它们通常被声明为从异常中恢复，并且可能进行“适当的清理”

我更喜欢从现有异常继承自定义异常类

---

在该新异常的构造函数中，将发生日志记录。这样，我将节省生成另一个带有完整跟踪的新异常的开销，以及随之而来的其他开销。

这取决于类之间的关系。一般来说，我更喜欢将日志记录委托给调用者。通常调用方也知道如何处理异常：重试？通知用户？日志忘记

---

在这个问题上也是如此。

记录异常并进一步抛出它实际上是一种反模式。经验法则是：如果您不能做任何有用的事情来处理异常（在大多数情况下，日志记录不会处理异常），那么让您的框架/容器来为您处理。如果可以（例如，当数据库不可用时使用不同的存储，当网络关闭时对包进行排队），则记录异常并继续（始终记住还要记录堆栈）

---

如果您有一个选中的异常，请将其包装在运行时1中并重试（创建您的自定义异常或查找符合您需要的现有异常）。

这不应该是原因，因为日志记录可能在更高级别（方法doSomething的调用方）中完成，并且从stacktrace中我们可以找出异常的位置。是的，但是，您可能不想在更高的级别上记录每个异常（出于某种原因），如果它是一个通用异常，则重铸到特定异常或添加消息可能有助于以更高级别的特定方式处理它。为什么每个人都觉得需要捕获异常？不要抓那些你无能为力的东西。如果不碰异常，异常会自动在堆栈中冒泡。完全没有理由重新抛出它们（这样做会产生负面后果，比如丢失有价值的信息）。如果你能用异常做点什么，那么，你就很可疑地接近使用异常进行流控制的领域，而你可能一开始就不应该这样做。