具有多种不同类型错误的业务组件

Question

这只是一个一般性的设计问题。如果您正在开发业务组件或服务(例如，公开相对简单的接口来处理计费事务的对象/服务)，那么有哪些处理业务相关错误的好方法？

假设组件/服务必须与几个不同的外部web服务集成，这些外部web服务都报告不同的错误，并且还必须在您这边执行一些数据库工作。有许多不同的事情可能会出错，无论是网络/数据库方面还是业务规则方面。尝试捕获组件中的所有类型的错误并使用错误代码方案将它们报告回调用者，或者尝试将所有错误包装为各种类型的异常并将其抛给调用者，是更好的做法呢？

这似乎很困难，因为使用异常来处理业务规则检查变得很笨拙，我在几个地方读到了避免使用异常来控制“非异常”或业务逻辑流。我觉得“例外”通常是一个有争议的术语，试图将不同的情况定义为“例外”与“非例外”会变得很棘手。(例如，如果您的业务逻辑检查支出限制、年龄限制等)。同时，使用错误代码方案也很笨拙，因为调用者可能会选择忽略错误代码。

任何提示或参考将不胜感激！

Answer 1

我选择了错误代码方案，因为你说了“很多不同的事情都可能出错”。您可能希望有一个返回错误对象列表的方案，其中Error将封装代码、解释、原始数据等。

异常只能说明一件事是错误的，它应该是“异常”性质的，而不是一个普通的问题。

或者使用混合方法抛出异常，该异常将Error对象列表作为私有数据成员，并使用允许您迭代错误的访问方法。

Answer 2

业务相关的错误不应该是exeptions。如果程序中存在程序设计不能处理的事件或完全不可预见的事件，则会出现异常。为此，如果您预计会有大量不同的异常，请务必实现一些有用的编号方案。出于组件重用的原因，我建议使用guid。每个组件都应该公开一些接口来查询可能的异常编号列表(然后可以将其添加到数据存储中以进行文档记录)。此外，当您重用组件时，错误代码将不会冲突。

另一方面，用户或业务数据错误几乎需要某种编号方案。几乎没有办法预料到用户能够使用做的所有愚蠢的事情。然而，我强烈反对正式的语言异常，而支持一些自定义的错误对象。语言异常可能会产生很大的开销，或者需要专门的处理来防止它们在调用堆栈中传播。业务错误对象很可能是一种很好的方法。

Answer 3

服务是边缘服务，特别是当它们必须受到各种语言的攻击时，这些语言可能无法正确处理SOAP异常。如果它在WWW上，也有安全方面的问题。

如果它不是服务，是内部的，和/或将被客户端以已知语言访问，则使用异常来处理失败条件。不保证客户端检查错误代码。

有关这方面的讨论，请参阅http://msdn.microsoft.com/en-us/library/ms229030.aspx。(这也在Framework Design Guidelines一书中。)