异常处理架构

Question

是否有人有异常处理的最佳做法？

在网上搜索时，我在代码级别找到了很多最佳实践（不要抓住一般异常，不要重新抛出新的异常等）。我要找的是更高级别的最佳实践，比如：

• 在应用程序中捕获ui级别的异常。
• 记录尽可能详细的信息，显示友好的错误消息
• 在更多类似于SOA的应用程序中区分功能异常（您要求特定客户并期望找到一个，但找不到）和技术异常（数据库脱机）
• 不要使用例外功能异常
• 区分致命和非致命异常
• 区分使重试成为可能或使重试完全无用的异常
• 警告维护人员的模式

非常感谢任何想法和帮助，谢谢。

Answer 1

@Ilya：

这可能是乔尔写过的最糟糕的文章之一（对于那些没有阅读过该链接的人，他认为“例外被视为有害”，所以不要使用它们。）

Joel有两个例外问题：

1. 它们在源代码中不可见。

   • 但未处理状态返回也是如此。正确处理状态 - 返回会使方法的正常流动变得混乱，使得它们更难以阅读。

2. 它们为函数创建了太多可能的退出点。

   • 等等什么？处理故障几乎总是要求您提前返回。明确退出点只会使代码混乱。

Ned Batchelder对Joel here的回复非常好（并且更长）。 Joel回复here，Ned再次回复here。

Brad Abrams也有关于例外here的价值的非常好的文章。

Answer 2

.NET Specific但肯定有一些有价值的信息。

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

Answer 3

我也喜欢区分：

• 由于函数调用者而导致的异常
• 由于函数内部错误导致的异常。

这对我来说是一个明确的分离方式：

• 动态异常（可能发生，但不需要明确捕获，谎言非法争论）
• 静态异常（必须明确处理，因为应用程序内部存在缺陷）

Answer 4

您可能会比查看Microsoft Exception Management Application Block的代码和文档更糟糕。对于很多场景来说，它可能有些过分，但它确实很全面。