异常与临时类型。什么情况下容易摔倒？

我在从事 MVC 3 项目时正在阅读一本企业应用程序开发的书。我目前正在决定如何处理异常。以前我会让异常在堆栈中冒泡，然后在最高层处理它。

这本书建议在域模型中创建一个临时类并返回它。例如。

public sealed class MissingCustomer: Customer
{

}

// On method failure return new MissingCustomer();

我可以理解这个想法，但我正在努力证明这样做的必要性。从代码角度来看，我同意返回一个新的失踪客户比抛出异常要整洁得多。

您对这种方法有何看法？您是否遇到过这种方法产生重大影响的情况？

如果我们假设客户必须始终存在，那么抛出异常说“嘿，客户应该始终存在，但由于某种原因不存在，所以我将通知用户发生了异常情况”是有意义的。另一方面，我可以假设客户有可能被另一个人删除，因此我需要优雅地处理这个问题。

无论哪种方式，我认为我们都需要 MissingCustomer 类或 MissingCustomerException，因为客户是整个系统中使用的非常常见的实体。如果视图模型需要一个客户并且我们返回一个 MissingCustomer - 这很好，因为继承将使这个工作正常。

例如，我有一个返回 OrderViewModel 的操作方法。此操作方法需要参考客户。

Customer customer = CustomerRepository.Find(10);
if(customer == null)
{
    return new MissingCustomer();
}

这将会失败，因为操作方法将返回 OrderViewModel 类型的视图模型，所以现在我更倾向于使用异常，而不是 MissingCustomer 对象。

Edit

此外，MissingCustomer 类型对象将从 Customer 类型继承属性。这些属性不是必需的，因为我们唯一要做的就是通知用户找不到客户。

谢谢

我总是会回来null来自用于获取客户的方法。只需查看名为的函数GetCustomer人们永远不会想到它会返回一个不是真正客户的客户对象。

最好使用类似的东西var customer = repos.GetCustomer(1) ?? Customer.Empty如果可以的话。意图很明确，代码也不容易出错。

如果您的方法期望始终获得客户，那么您之前未能验证输入。与其创建解决方法来使代码正常工作，不如尝试尽早修复它。也许检查一下客户是否存在？

Update

我现在注意到这个问题确实是针对您的视图模型的。在其中使用这种逻辑是完全可以的。视图模型毕竟用于调整 MVC 中的“M”以适应视图（因此从视图中删除逻辑）。

我会用

public class YourViewModel
{
    public Customer Customer { get { return _customer ?? Customer.Empty; }}
}