Question

无论如何，我对于何时传播异常以及何时将其包装以及差异感到困惑。

目前，我的理解告诉我，包装异常将涉及像DriveNotFound（在IO中）那样的异常，然后用普通的IOException包装它。

但是传播异常的概念，如果我有一个空的catch子句，这只会发生吗？因此，在ASP.NET Web应用程序中，它将传播到global.asax。或者在最近部署的Web应用程序的情况下，未处理的HTTPException给出了一个黄色的死亡屏幕，并写了一个日志到Windows Server（这是一个我正在重写的Web应用程序）。因此异常发生在一个方法中，它可以在类级别处理，显示在页面中，然后转到global.asax或Windows Server。

为什么我要用更通用的异常包装异常？规则是处理具有最特定类型的异常（因此DriveNotFound显然找不到驱动器）。另外，我如何选择换行和替换异常？

异常处理链是try和catch（或catches）子句吗？我从措词中假设，是的。

最后，为什么以及如何让异常传播到callstack？

我确实阅读了有关异常处理的MS PandP指南，但我想这些示例并没有让我充分理解所有内容。

这个问题来自Enterprise Library能够包装/传播异常等等。这是我不确定的传播，以及替换/包装异常的区别。

此外，可以在catch块中插入复杂的错误处理逻辑（例如ifs / elses和类似的东西）。

由于

Answer 1

这一切都是为了向呼叫者传达正确的意义。我怀疑是否有理由将一个特定的例外包装在一个更通用的例外 - 这对任何人都没有帮助。

考虑一个与文件访问无关但在后台访问配置文件的API。如果配置文件不存在，您可以将FileNotFoundException包裹在ConfigurationException中，以便将正确的问题传达给呼叫者。

为什么以及如何让我这样做异常传播到callstack？

如果无法处理异常，就会传播异常。就这么简单。如果您的代码无法或应该做什么来解决异常，那么让它传播。在传播时，要小心你这样做：

throw ex;

与：

不同

throw;

前者抛弃旧的堆栈跟踪，并从抛出异常的点开始创建另一个。后者保留了原始堆栈跟踪。

当然，如果您无法处理异常，那么您可能不会在第一时间抓住它（可能您想要记录）。

Answer 2

关于这方面已经有了很多很好的答案和讨论。见这里：

Best Practice for Exception Handling in a Windows Forms Application?

Answer 3

我通常这样做：

业务逻辑程序集（dll）不处理异常，除非他们完全理解
预期但不可处理的异常包含在单个异常类型中，并允许汇总调用堆栈（即，在数据库交互期间可能发生的所有不同异常都包装在单个RepositoryException中并抛出）< / LI>
允许传播意外的异常（永远不要在dll中包含catch(Exception ex)）
仅在最后一刻处理异常（即UI的控制器）

它通常只在调用堆栈中很远，你知道你正在做什么（当前的业务流程是什么）以及如何正确处理异常。

Answer 4

这是我在.NET中实现一致的异常处理策略的最佳资源

http://msdn.microsoft.com/en-us/library/cc511522.aspx

异常处理实践

5 个答案: