2011-04-02 78 views
2

我正在开发一个代码块,由以前的开发人员编写,他根本不喜欢处理异常!是否有异常处理的标准?如果是的话,请提供链接

我不知道我是否能找到关于异常处理的一般指导。

例如:假设有一个方法负责在数据库中执行查询,如果它在连接失败,那么它是否应该向调用者抛出相同的异常?或者它应该只处理它并记录它并返回false(意味着失败)。

我知道这个问题似乎是主观的,我只是想要任何资源,指导方针或标准的异常处理。

问候。

+2

试试这个[良好的例外管理规则] http://www.hanselman.com/blog/GoodExceptionManagementRulesOfThumbBackToBasicsEdition.aspx – 2011-04-02 15:05:45

+0

这是什么类型的应用程序?的WinForms? ASP.NET? – 2011-04-02 15:07:02

+0

@Justin E. Morgan:Web服务。 – Homam 2011-04-02 15:09:45

回答

5

如果你问10位开发人员,你可能会得到10个不同的答案。我生活的一般规则是异常处理应该标准化,不要在每一种方法中重复。我试图争取例外以一致的方式每层处理一次。因此,在一个标准的三层体系结构(表示,业务,数据)中,每层都有一个标准的异常处理机制,并且所有这三种机制都会在幕后调用相同的日志记录/通知/等等。

这里是链接到Microsoft's Best Practices

3

异常处理是一个“关注”问题,因此不应将其分散在您的应用程序中,并与核心业务逻辑混合在一起。这个领域可能会以与您的业务逻辑不同的速度发展。

例如你提到打开数据库连接。您可以通过记录异常开始,但稍后可能会确定它应该在超时时自动重试,或发送警报,或者实施Circuit Breaker Pattern也许适合。

坚持单一责任原则和关注点的分离使您能够独立演变您的异常处理行为。考虑这个接口:

public interface IConnectionFactory 
{ 
    IConnection Create(); 
} 

如果你不做任何异常在基础实施方式处理,允许你使用继承,装饰图案或您的构架的一些设施,以增加额外的行为。

public class RetryOnTimeoutConnectionFactory { ... } 
public class CircuitBreakerConnectionFactory { ... } 

要考虑的另一件事是上下文。你提到这是网络服务。那么,如果您遵循REST语义,则可能会将异常转换为HTTP状态代码,具体取决于异常的分类。如果你将你的例外陷入低水平,并且默默地返回false那么你真的会手铐自己。

相关问题