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

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

一个例外只能说明一件事是错误的,它应该是一个“例外”性质的,而不是一成不变的问题。

或者可能是一个混合体,其中抛出一个异常,该异常将一个错误对象列表作为私有数据成员,并使用一个访问方法来迭代错误。

与业务相关的错误不应是例外。如果程序中的某个事件不是为处理或完全不可预见而设计的,则会出现异常。

另一方面,用户或业务数据的错误几乎需要一些编号方案。 几乎没有办法预料到用户能够做的所有愚蠢的事情

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

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

见 http://msdn.microsoft.com/en-us/library/ms229030.aspx 为了好好讨论这个。(也在书中 Framework Design Guidelines .)

完全没有什么可以阻止您将业务规则和技术规则冲突都作为例外。我会在两种情况下使用异常:

1. 违反先决条件 知道这个 ,无论如何指定更大的限制,将异常直接抛出给他!

2. 违反条件后 . 如果满足所有前提条件,但是 由于意外的拒绝 (例如数据库连接;或交易完成违反反垄断法)您无法提供正确的结果,请不要提供。抛出异常。

可能 在一个组件中,不依赖任何其他组件,业务异常的案例2非常罕见。在前端应用程序中,应该检查属于案例1的内容。这使我认为不抛出业务逻辑异常的方法不是 ,但很可能 你基本上不需要 ".

无论如何,从编程语言的角度来看,它很难注意到“技术”异常和“业务”异常之间的区别,因此它可以正确地处理它们。其次,在某些地方会发现异常。我想,从架构师的角度来看,业务和技术异常将被捕获到不同的组件中。当然,除非它们实际上没有被发现,否则仅显示错误消息而不进行程序处理就属于这一类。因此,使用相同的机制不会使您混淆这些错误。