2

例如，如果您将汽车传递给使用应该检查空引用的汽车的子系统？

我是否应该费心将这段代码包装在下面的 if 语句中？这似乎很多余，显然我可以举一个更好的例子，因为我无法捕获异常并以任何方式处理它。

还是我应该让异常冒泡给调用者？

例如：

Public Sub CarService(ByVal car As ICar)
    If car IsNot Nothing Then
        'do logic here 
    Else : Throw New ArgumentNullException
    End If
End Sub
4

5 回答 5

4

扔一个NullReferenceException自己实际上是没有意义的。因为这是

  1. CLR 将引发的相同异常（至少在您访问手动检查的相同引用时null）和
  2. 无论如何都气馁。请参阅此处的备注 。有关相关讨论，请参阅是否有必要从扩展方法中抛出 NullReferenceException？.

但是，至少对于公共 API 表面，您应该检查空引用并抛出ArgumentNullException.

Public Sub CarService(ByVal car As ICar)
    If car Is Nothing Then
        Throw New ArgumentNullException("car")
    End If
    ' do logic here
End Sub

或查看Code Contracts。

于 2012-11-09T07:48:08.507 回答
1

我认为这是一个好主意，因为您可以防止代码不可预测。由于异常取决于以下代码并且可以随其更改。使用您的代码，您就知道在哪里以及可以抛出什么异常。

您唯一应该考虑的是您应该使用什么异常，甚至创建一个自己的异常。由于 NullReference 似乎有点错位。

于 2012-11-09T07:48:08.570 回答
1

我想这取决于场景。在某些情况下，null将有效值传递给方法。null如果不是，那么您需要权衡在代码到达对象之前会发生多少逻辑。如果在那之前没有发生任何重大事件，那么您可以简单地让它冒泡。如果您在使用该对象之前确实进行了重要操作，那么在您输入该方法时就值得检查一下。此外，如果您有多个对象，那么调用者将不知道是哪一个导致了问题，因此您可能会自己抛出异常，并添加适当的错误消息。

于 2012-11-09T07:49:07.007 回答
1

由你决定。

如果NULLs 是您逻辑的一部分，则在您的方法中处理它CarService。例如，在您的代码中，一辆NULL汽车可能意味着它是一辆未知的汽车，在这种情况下，您必须为其编写逻辑。

如果您不应该通过NULL. 这样边缘情况将在调用方处理。例如，如果您的代码执行以下操作： 

Public Sub CarService(ByVal car As ICar)
    car.ToString();
End Sub

在这种情况下，显式抛出错误是有意义的，这将在整个框架中保持一致。

于 2012-11-09T07:49:39.357 回答
1

In my opininion throwing the NullReferenceException yourself is nonsense (CLR will do it for you). But on the other hand throwing the ArgumentNullException is a good practice for me. If error occurs, you know exactly where the problem is and which parameter cannot be null. To save time writting such ever-repating code I use macros in ReSharper (no problem to get under 2 seconds).

于 2012-11-09T08:02:45.440 回答