coding-style - 对《清洁代码》一书中关于处理 Null 对象的 Bob 叔叔解释感到困惑

Question

我今天正在阅读 Bob 叔叔关于异常处理的书，我从处理 null 值中回想起的是，方法不应该处理 null 值，因为它会使代码变得困惑。我有点困惑。
我一直认为一个方法应该始终确保它的依赖项不为空(除非它们被注入(inject)构造函数并且构造函数确保可空性)。
例如，如果我有一个方法

public void SendMessage(IEmailSender emailSender, contactList list)
{
    if(emailSender == null)
    {
         throw new ArgumentNullException("Failed to send  
                message.",MethodBase.GetCurrentMethod().GetParameters[0].Name);
    }
    if(list == null)
    {
         throw new ArgumentNullException("Failed to send  
                message.",MethodBase.GetCurrentMethod().GetParameters[1].Name);
    }

    // rest of code goes here

}

我错过了什么吗？

Answer 1

有两种观点:
一方面，通过你的方法，你总是会通过调用你的方法来告诉调用者他到底做错了什么。这对来电者来说非常有用，因为当他收到您的异常时，他可以立即修复它。如果您在编写第三方使用的 API 代码，这将是真实有效的。

另一方面，如果您自己调用您的方法，那么抛出异常的合理参数是，因为您希望能够在调用代码中使用 catch block 来处理这种情况!如果您没有理由在某处处理它，为什么要抛出异常呢？我看到的唯一原因是，通过在 GlobalExceptionHandler 中捕获这些异常来进行详细的错误日志记录。

所以你看我们这里有两类异常:一类是给开发者的，用来避免 API 的错误使用，另一类是作为方法的错误结果。

如果您正在编写将被其他人使用的 API 代码，您的选择是，不听 Bob ;-)

对于那些没有读过 CleanCode 的人，Bob 建议了两件事:

1.你不应该写的方法返回空值 (避免事后进行不必要的检查)。所以不要写这个:

var myObject = GetObjectThatDoesSomthing();  
if(myObject != null)  
{  
myObject.DoSomething();  
}

...你应该可以这样写:

var myObject = GetObjectThatDoesSomething();  
myObject.DoSomething();  

清洁器。

2.你不应该 通过 null 到您的方法，以避免在方法开始时进行不必要的检查，如下所示:

public Point Add(Point p1, Point p2)  
{  
    if(p1 == null) throw ArgumentException();  
    if(p2 == null) throw ArgumentException(); 
    ... 
}

这些规则的要点是:如果你坚持下去，你就知道你不必编写这些空值检查，你的代码会变得更清晰、更容易阅读。但是在您使用第三方代码的那一刻，您无法判断他们是否在其 API 中应用了相同的规则，因此您开始再次进行预检查或后检查。当您为他人编写 API 时也是如此:您 API 的使用者如何知道您在编写代码时考虑了 Bobs 规则......