异常处理架构 [英] Exception handling architecture

问题描述

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

Does anybody have best practices for exception handling ?

在网上搜索我发现了很多在code的最佳做法（不抓一般例外，不重新抛出新的异常等），我所寻求的是更高层次上的最佳实践，这样的东西：

When searching the web I find a lot of best practices on a code level (don't catch general exceptions, don't rethrow new exceptions etc.) What I am looking for is best practises on a higher level, stuff like :

• 在用户界面级别的应用程序捕获异常之内。


• 请尽量详细越好，显示出友好的错误消息


• 在更像是应用程序的SOA功能异常区分（你问一个特定的客户，并希望找到一个，但发现没有）和技术异常（数据库脱机）


• 请不要使用功能异常之外


• 致命和非致命异常区分


• 的异常，使重试或可能重试做毫无用处
区分

• 图案为提醒维修人员

有什么想法和帮助是很大的AP preciated，谢谢。

Any thoughts and help are greatly appreciated, thanks.

推荐答案

@Ilya：

这可能是乔尔曾经写文章最差的一个（对于那些谁没有读过的联系，他是主张认为是有害的例外，所以不要使用它们）。

That is probably one of the worst article Joel has ever written (for those who haven't read the link, he is arguing "Exceptions considered harmful", so do not use them).

乔尔有两个问题有例外：

Joel has two problems with exceptions:

1. 他们是在源$ C ​​$ C看不见的。

1. They are invisible in the source code.

• 但是这样是未处理状态-回报。并妥善处理状态，回报弄乱方法的正常流动使得它们更难阅读。

他们为函数创建过多可能退出点。

They create too many possible exit points for a function.

• 还等什么？处理失败几乎总是要求你提前返回。使得出口点明确只会弄乱code。

斯内德尔德拥有一支优秀的（和更长），这里回复乔尔。乔尔这里有一个很短的答复，对此斯内德再次回复的here 。

Ned Batchelder has an excellent (and much longer) reply to Joel here. Joel has a short reply here, to which Ned replies again here.

布拉德·艾布拉姆斯也对这里的价值一个非常好的文章>。

Brad Abrams also has a very nice article on the value of exceptions here.

这篇关于异常处理架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！