异常处理架构

标签 exception architecture

有人有异常处理的最佳实践吗?

在网上搜索时,我发现了很多代码级别的最佳实践(不捕获一般异常,不重新抛出新异常等)。我正在寻找的是更高级别的最佳实践,例如:

  • 在应用程序内捕获 UI 级别的异常。
  • 记录尽可能多的详细信息,显示友好的错误消息
  • 在更多类似 SOA 的应用中,会区分功能异常(您询问特定客户并希望找到一个客户,但实际上一无所获)和技术异常(数据库离线)
  • 不要将异常用于功能异常
  • 区分致命异常和非致命异常
  • 区分使重试成为可能或使重试完全无用的异常
  • 提醒维护人员的模式

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

最佳答案

@伊利亚:

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

Joel 有两个异常问题:

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

    • 但未处理的状态返回也是如此。正确处理的状态返回会扰乱方法的正常流程,使它们更难以阅读。
  2. 它们为函数创建了太多可能的退出点。

    • 那又怎样?处理失败几乎总是需要您提前返回。明确退出点只会使代码变得困惑。

内德·巴切尔德 (Ned Batchelder) 对乔尔 (Joel) 的回复非常出色(而且更长)here 。乔尔有一个简短的回复here ,Ned 再次回复 here .

Brad Abrams 还有一篇关于异常值(value)的非常好的文章 here .

关于异常处理架构,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/242587/

相关文章:

c# - Winforms 绘图 - 参数在系统恢复时无效

architecture - 接口(interface)在多层应用程序中属于什么地方

c# - C# 中跨平台类的设计

分层可重用架构的框架

elasticsearch - AWS Elasticsearch 作为主数据库

java - 如何在tomcat的catalina.out中使用Spring MVC获取错误消息

退出整个程序时出现python线程异常错误

python - 异常处理: Differentiating between instances of the same error in Python

c++ - 如何将异常报告给 boost::future?

c# - 使用 Automapper 和 Autofac 时为不可访问的实例指定构造函数