MethodA调用MethodB，然后依次调用MethodC。

在MethodB或MethodC中没有异常处理。但是在MethodA中有异常处理。

在MethodC中发生异常。

现在，该异常正在冒泡到MethodA，该方法可以适当地对其进行处理。

这有什么问题？

在我看来，在某个时候调用者将执行MethodB或MethodC，并且当这些方法中确实发生异常时，从这些方法内部处理异常中可以获得什么，这实际上只是一个try / catch / finally块，而不仅仅是让他们冒泡给被呼叫者？

围绕异常处理的陈述或共识是，仅在执行不能继续执行时抛出该异常。我明白了。但是，为什么不在链的更深处捕获异常，而不是让try / catch块一直向下传播。

当您需要释放资源时，我会理解的。完全是另一回事。

作为一般原则，除非您知道如何处理异常，否则不要捕获异常。如果MethodC抛出异常，但是MethodB没有有用的方法来处理它，则它应允许异常传播到MethodA。

方法应具有捕获和重新抛出机制的唯一原因是：

• 您想要将一种异常转换为对上面的调用者更有意义的另一种异常。
• 您想要向异常添加其他信息。
• 您需要一个catch子句来清理没有一个资源就会泄漏的资源。

否则，在错误的级别捕获异常会导致代码默默地失败，而不会向调用代码（以及最终的软件用户）提供任何有用的反馈。捕获异常然后立即将其重新抛出的替代方法是没有意义的。

这有什么问题？

绝对没有。

现在，该异常正在冒泡到MethodA，该方法可以适当地对其进行处理。

“妥善处理”是重要的部分。这就是结构化异常处理的症结所在。

如果您的代码可以通过Exception做“有用的”事情，那就去做吧。如果没有，那就别说了。

。。。为什么不在链的更深处捕获异常，而不是一直将try / catch块一直拖下去。

那正是你应该做的。如果您正在阅读的处理程序/重新抛出器“一直向下”的代码，那么您（可能）正在阅读一些非常糟糕的代码。

可悲的是，有些开发人员只是将catch块视为他们编写的每个方法都放入的“样板”代码（没有双关语），通常是因为他们并没有真正“获取”异常处理，并认为他们必须添加一些东西。例外不会“逃脱”并杀死他们的程序。

这里的困难的部分原因是，大部分的时间，这个问题甚至不会注意到，因为异常没有被抛出的所有的时间，但，当他们是，该程序会浪费非常多的时间和逐步取消调用堆栈，直至到达对Exception确实有用的地方。

您必须在库和应用程序之间有所作为。

图书馆可以自由引发未捕获的异常

设计库时，有时必须考虑可能出什么问题。参数的范围可能错误或null，外部资源可能不可用，等等。

您的图书馆通常没有办法以明智的方式处理它们。唯一明智的解决方案是引发适当的Exception，并让Application的开发人员处理它。

应用程序应始终在某些时候捕获异常

当捕获到异常时，我喜欢将它们归类为Errors或致命错误。常规错误表示我的应用程序中的单个操作失败。例如，由于目标不可写，因此无法保存打开的文档。应用程序要做的唯一明智的想法是通知用户操作无法成功完成，提供有关该问题的人类可读信息，然后让用户决定下一步要做什么。

甲致命错误是一个错误的主应用程序逻辑不能从恢复。例如，如果图形设备驱动程序在视频游戏中崩溃，则该应用程序无法“优雅地”通知用户。在这种情况下，应写入日志文件，并且如果可能，应以某种方式通知用户。

即使在这种严重情况下，应用程序也应该以有意义的方式处理此异常。这可能包括编写日志文件，发送崩溃报告等。应用程序没有理由不以某种方式响应异常。

您描述的模式有什么问题，即方法A无法区分三种情况：

1. 方法B以预期的方式失败。

2. 方法C失败的方式不是方法B所预期的，而是方法B正在执行可以安全地放弃的操作时。

3. 方法C失败的方式不是方法B所预期的，而是方法B执行操作时，将事物置于假定为暂时的非相干状态，由于B的失败，B无法清理该状态。

方法A能够区分这些情况的唯一方法是，如果从B抛出的异常包括足够用于该目的的信息，或者方法B的堆栈展开导致对象处于显式无效状态。不幸的是，大多数异常框架使这两种模式都变得笨拙，迫使程序员做出“更少邪恶的”设计决策。