好/坏业务对象设计?

最近我和一位同事就这个话题进行了一场辩论。

我的断言是,在这种情况下,您希望做X的方法不做X,这就是异常的定义。

你选择用这个例外来做的是另一个故事。您可以选择在代码中对其进行内部处理,也可以选择将异常的处理推迟到代码中的更高级别。

我同意,如果在发生异常的时间和地点处理异常是有意义的,那么处理异常总是更好的,而不是将其延迟到更高的代码级别。

也就是说,我相信在较低的代码级别中,将这些异常的处理推迟到较高的代码级别是有意义的。这就提供了更高级别的代码,在处理这些情况的方式上具有更大的灵活性,同时也提供了更高级别的代码洞察发生了什么。

例如,如果您从数据库中检索数据并构建一个对象以在应用程序中使用,则可能会发生以下几种情况:

1. 按预期返回对象。
2. 无法连接到数据库。
3. 找不到您希望找到的数据。

您可以通过简单地返回空对象或空值来处理异常2和3,但是更高级别的代码不知道为什么它请求的信息没有返回。这需要一些次要的模式来通知更高级别的发生了什么。

或者,我断言您可以创建一个带有消息字段的自定义异常,在该字段中传递发生的异常事件。强制更高级别的代码在适当的时候处理这些情况。

在我看来,后者可能更灵活,但确实需要更高级别的代码来知道它需要处理异常,这些异常应该有很好的文档记录,以便其清晰的方法可以抛出某些异常。

注:我不是专家,我不自称是专家,在与我讨论这个话题的同龄人的鼓励下,我分享了我的观点。

imho,异常是针对异常情况的——丢失的数据通常不是异常的,除非它位于主键或其他非空字段上。

这取决于数据丢失对应用程序的影响。如果没有数据,应用程序无法合理地继续运行,那么这是一个例外情况,并且例外是有保证的。如果数据丢失是相对正常的(尤其是如果期望调用者处理异常并继续执行),那么这就是异常的使用,这是一种糟糕的设计。