异常处理架构

Question

有没有人有异常处理的最佳实践？

在网上搜索时,我在代码级别找到了很多最佳实践(不要抓住一般异常,不要重新抛出新的异常等).我所寻找的是更高级别的最佳实践,例如:

• 在应用程序中捕获ui级别的异常.
• 记录尽可能详细的信息,显示友好的错误消息
• 更像SOA的应用程序区分功能异常(您要求特定客户并希望找到一个,但找不到)和技术异常(数据库脱机)
• 不要将异常用于功能异常
• 区分致命和非致命异常
• 区分使重试成为可能或使重试完全无用的异常
• 提醒维护人员的模式

非常感谢任何想法和帮助,谢谢.

Answer 1

@Ilya:

这可能是乔尔写过的最糟糕的文章之一(对于那些没有阅读过该链接的人,他认为"异常被视为有害",所以不要使用它们).

Joel有两个例外问题:

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

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

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

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

Ned Batchelder 在这里对Joel的回复非常好(而且更长).乔尔在这里有一个简短的回复,奈德在这里再次回复.

布拉德·艾布拉姆斯也有例外的价值很不错的文章在这里.

Answer 2

我还喜欢区分：

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

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

• 动态异常（可能会发生，但不需要显式捕获，例如非法参数）
• 静态异常（由于应用程序内部的缺陷，必须显式处理）