好/坏业务对象设计？

Question

我继承了一套业务对象，它们工作得很好。它看起来好像是基于Rockford Lhotka的CSLA框架，但有一个非常烦人的问题。当业务对象执行加载时，它会抛出异常。因此，如果它尝试加载数据库中不可用的某些数据，则会抛出异常。这是好设计吗？

Answer 1

恕我直言，例外是针对特殊情况 - 缺少数据通常不例外，除非它在主键或其他非空字段上。

Answer 2

这取决于丢失数据对应用程序的影响。如果应用程序无法在没有数据的情况下合理地继续，那么这是一个例外情况，并且有必要例外。如果数据丢失是相对正常的（特别是如果调用者应该处理异常并继续），那么这就是使用异常的设计。

Answer 3

我最近一直在与同事讨论这个话题。

这是我的断言，你希望做X的方法不能做X的情况就是异常的定义。

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

我同意处理异常总是更好，如果它发生的时间和地点都是有意义的，而不是将其推迟到更高级别的代码。

这就是说我也相信在较低级别的代码中，将这些异常的处理推迟到更高级别的代码是有意义的。这为处理这些情况的代码提供了更高级别的代码，并且还提供了更高级别的代码洞察力。

例如，如果您从数据库中检索数据并构建一个对象以便在您的应用程序中使用，您可能会发生以下几件事情：

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

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

或者我断言你可以创建一个带有消息字段的自定义异常，在该字段中可以传回发生的异常事件。强制您的更高级代码在其认为合适的情况下处理这些情况。

在我看来，后者可以更灵活，但需要更高级别的代码才能知道它需要处理应该被详细记录的异常，以便明确方法可以抛出某些异常。

注意：我不是专家，我不是自称，我在与同行一直在讨论这个话题的同伴的鼓励下分享我的意见。