这只是一个普遍的设计问题。如果您正在开发业务组件或服务（例如，公开相对简单的用于处理账单处理事务的接口的对象/服务），那么处理业务相关错误的一些好方法是什么？业务组件与许多不同类型的错误
假设组件/服务必须与几个不同的外部Web服务集成，这些服务都会报告不同的错误，并且还必须在您身边做一些数据库工作。有许多不同的事情可能会出错，无论是网络/数据库方式还是业务规则方面。尝试捕获组件中的所有类型的错误并使用错误代码方案将其报告给调用者，或者尝试将所有错误包装成各种类型的异常并将它们传递给调用者，会更好吗？
这似乎是一个挣扎，因为处理使用异常的业务规则检查很尴尬，而且我已经在几个地方读过，以避免使用异常来控制“非例外”或业务逻辑流。我认为“特殊”往往是一个有争议的术语，它试图将不同情况定义为“例外”与“非例外”之间的粘性。 （例如，如果您的业务逻辑检查支出限额，年龄限制等）。同时，使用错误代码方案也很尴尬，因为调用者可能会选择忽略错误代码。
任何提示或参考将不胜感激！
我会去错误代码方案，因为你说“许多不同的事情可以出错”。您可能想要一个返回Error对象列表的方案，其中Error将封装代码，说明，原始数据等。
一个异常只能告诉一件事情是错误的，它应该是一个“特殊的“性质，而不是普通的问题。
或者可能是一个混合体，您可以抛出一个包含Error对象列表的异常作为私有数据成员的异常以及允许您迭代错误的访问方法。
业务相关的错误不应该是豁免。如果程序中没有设计用于处理或不完整的事件，则会有例外。 为此，如果您预计有大量不同的例外情况，请采取一切有效的编号方案。在这里，我会建议一个guid的组件重用的原因。每个组件都应该公开一些接口来查询可能的异常编号列表（然后可以将其添加到数据存储中以进行文档编制）。同样当你重用组件时，错误代码不会发生冲突。
另一方面，用户或业务数据错误几乎保证一些编号方案。 几乎没有办法预测用户有能力的所有愚蠢的东西。但是，我强烈劝阻形式化语言异常，以支持某些自定义错误对象。语言异常可能会产生大量开销，或者需要专门的处理来防止它们传播堆栈。业务错误对象可能是一个很好的方法。
服务是边界线，特别是如果它们必须从各种语言中打中，这些语言可能无法正确处理SOAP异常。如果它在WWW上，也有安全问题。
如果它不是服务，是内部的，和/或将被客户端以已知语言访问，请使用异常来处理失败情况。客户不保证检查错误代码。
为这个伟大的讨论，请参见 http://msdn.microsoft.com/en-us/library/ms229030.aspx 。 （它也在书Framework Design Guidelines中。）
绝对没有什么能够阻止您制定业务规则和技术规则违规例外。我会在两种情况下使用异常：
前提违反。如果你的函数的规范说“所花费的金额不应超过这种类型的帐户的限制”，并且用户，知道这个，无论如何指定更大的限制，抛出异常权利！
违反事项后遗症。如果所有先决条件都满足，但因意外拒绝（例如数据库连接;或者交易完成违反反垄断法），则不能提供正确的结果，请不要提供。抛出一个异常。
由于所有的业务逻辑可能是一个组件内，不依赖于任何其他情况2对业务异常是相当罕见的。应该在前端应用程序中检查情况1。这使我认为不抛出业务逻辑异常的方法不是你“不应该做”，但可能“你大多不需要”。
无论如何，从编程语言的角度来看，它几乎不会注意到“技术”和“业务”异常之间的区别，所以它会正确处理它们。其次，例外被捕获到某处。我想，从架构师的角度来看，业务和技术例外将被捕获到不同的组件中。当然，除非它们被有效地捕获，否则仅仅在没有编程处理的情况下显示错误消息就属于这一类。所以使用相同的机制不会让你混合这些错误。
所以，我的观点是，如果您选择不推翻异常作为编程概念，您也可以将它们用于业务逻辑。