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 回答