在哪里检查对象是否为空？

发布于 2024-07-16 08:54:57 字数 761 浏览 5 评论 0原文

在哪里检查传递给方法的对象是否为 null？

在调用方法之前是否需要测试对象？或者在使用参数的方法中？

public class Program
{
    public static void Main(string[] args)
    {
        // Check if person is null here? or within PrintAge?

        PrintAge(new Person { Age = 1 });
    }

    private static void PrintAge(Person person)
    {
        // check if person is null here?

        Console.WriteLine("Age = {0}", person.Age);
    }
}

public class Person
{
    public int Age { get; set; }
}

在两个类中进行“空”检查似乎是太多冗余代码。

[编辑]：在调用者或被调用者中检查 null 的缺点/优点是什么？

[EDIT2]：我刚刚遇到了防御性编程，看起来像它提倡在被调用者中检查 null。我想知道这是否是一种被广泛接受的做法。

原文

Where do you check if an object that you are passing to a method is null or not?

Should an object need to be tested before calling a method? or within the method that is using the argument?

public class Program
{
    public static void Main(string[] args)
    {
        // Check if person is null here? or within PrintAge?

        PrintAge(new Person { Age = 1 });
    }

    private static void PrintAge(Person person)
    {
        // check if person is null here?

        Console.WriteLine("Age = {0}", person.Age);
    }
}

public class Person
{
    public int Age { get; set; }
}

Having a "null" check in both classes seem to be too much redundant code.

[EDIT]: What would be an dis/advantage of checking for null within a caller or a callee?

[EDIT2]: I just ran into Defensive Programming and it seems like it advocates checking null within a callee. I wonder if this is a widely accepted practice.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

自由如风 2024-07-23 08:54:57

如果你设计一个库，就会有暴露给外部世界的方法。您应该检查此方法中传入的数据。在您不公开的方法中不需要进行检查，因为只有您的代码调用它们，并且其逻辑应该处理您在所调用的公开方法中接受的所有情况。

                    --------------------------
                   |                          |
                   |         Library          |
                   |                          |
 -------        ---------        ----------   |
|       |      |         |      |          |  |
| Outer |      | Library |      | Library  |  |
|       | ===> | Entry   | ===> | Backend/ |  |
| World |      | Method  |      | Helpers  |  |
|       |      |         |      |          |  |
 -------        ---------        ----------   |
                   |                          |
                   |                          |
                    --------------------------

如果您已经接受了输入方法中提供的数据，则应该执行请求的操作并返回预期的结果，即处理所有剩余的情况。

更新

澄清图书馆内部的情况。可能存在空检查，但这只是因为逻辑，而不是因为参数验证。库内空检查的位置有两种可能性。第一个如果被调用的方法知道如何处理空值。

private CallingMethod()
{
   CalledMethod(someData);
}

private CalledMethod(Object parameter)
{
   if (parameter == null)
   {
      // Do something
   }
   else
   {
      // Do something else
   }
}

第二种情况是调用无法处理空值的方法。

private CallingMethod()
{
   if (someData == null)
   {
      // Do the work myself or call another method
   }
   else
   {
      CalledMethod(someData);
   }
}

private CalledMethod(Object parameter)
{
   // Do something
}

整个想法是拒绝您无法立即处理的案件并妥善处理所有剩余案件。如果输入无效，则会抛出异常。这迫使库调用者仅提供有效值，并且不允许调用者以无意义的返回值继续执行（除了调用者浅化异常并继续）。

If you design a library, there will be methods exposed to the outer world. You should check the incoming data in this methods. No checks are required in methods that you do not expose, because only your code calls them and its logic should handle all cases you accepted in the exposed method called.

                    --------------------------
                   |                          |
                   |         Library          |
                   |                          |
 -------        ---------        ----------   |
|       |      |         |      |          |  |
| Outer |      | Library |      | Library  |  |
|       | ===> | Entry   | ===> | Backend/ |  |
| World |      | Method  |      | Helpers  |  |
|       |      |         |      |          |  |
 -------        ---------        ----------   |
                   |                          |
                   |                          |
                    --------------------------

If you have accepted the supplied data in the entry method, you should perform the requested action and return the expected result, that is handle all remaining cases.

UPDATE

To clarify the situation inside the library. There might be null checks, but only because of the logic, not because of parameter validation. There are two possibilities for the location of null checks inside the library. The first one if the called method knows how to handle null values.

private CallingMethod()
{
   CalledMethod(someData);
}

private CalledMethod(Object parameter)
{
   if (parameter == null)
   {
      // Do something
   }
   else
   {
      // Do something else
   }
}

And the second situation if you call a method that cannot handle null values.

private CallingMethod()
{
   if (someData == null)
   {
      // Do the work myself or call another method
   }
   else
   {
      CalledMethod(someData);
   }
}

private CalledMethod(Object parameter)
{
   // Do something
}

The whole idea is to reject cases you cannot handle immediately and handle all remaining cases properly. If the input is not valid you throw an exception. This forces the library caller to supply only valid values and does not allow the caller to continue execution with meaningless return values (besides the caller shallows the exception an continues).

回复收藏 0 原文

梅窗月明清似水 2024-07-23 08:54:57

您在 Main 中没有任何需要检查的内容 - 您使用的 new 运算符永远不会返回 null（Nullable 除外）。

检查 PrintAge 是完全合理的，特别是如果它被公开的话。（对于私有 API，进行参数检查不太重要，但它仍然非常有用。）

if (person == null)
{
    throw new ArgumentNullException("person");
}

在 C# 3.0 中，我通常为此使用扩展方法。

You've got nothing to check in Main - you're using the new operator which never returns null (except for Nullable<T>).

It would be entirely reasonable to check in PrintAge, particularly if it were made public. (For private APIs it's less important to do argument checking, but it can still be very useful.)

if (person == null)
{
    throw new ArgumentNullException("person");
}

These days in C# 3.0 I usually use an extension method for this.

回复收藏 0 原文

夜清冷一曲。 2024-07-23 08:54:57

您可以设计一种仅使用有效对象的方法。

这意味着您希望收到有效对象（在您的情况下不为空）。
这意味着您不知道如何做出反应以及如何处理无效对象：

从函数中静默返回
不是解决方案；
抛出异常意味着您将责任移交给上层
方法，它们可以在传递给您之前检查值。

因此，如果您的方法不确切知道如何处理无效对象，并且该方法在无效情况下不会遵循额外的逻辑，您应该将其放在

Debug.Assert( Person );

PrintAge 开始，这将强制您通过调用堆栈进行检查。

层次结构中越低的功能，它应该执行的检查越少。以下是在执行该工作的函数中进行检查的缺点。

正在做实际工作的函数
必须尽可能清楚
如果没有大量的 if
函数将会被调用很多次
这样的函数可以调用这样的函数并且它们可以再次调用这样的函数。他们每个人都会执行相同的验证

You can design a method to work with valid objects only.

That means you are expect to receive valid objects ( not null in your case ).
That means you don't know how to react and what to do with invalid objects:

returning silently from the function
is not a solution;
throwing an exception will mean you move responsibility to the upper
methods where they can check the value already before passing to you.

So if your method don't know exactly how to handle invalid object and the method won't follow additional logic in the invalid case you should put

Debug.Assert( Person );

at the PrintAge begin and this will force you to make checks upper by call stack.

The lower function in hierarchy is the less checks it should do. The following is disadvantages of doing checks in the functions that do the work.

Function that is doing actual work
has to be as clear as possible
without mass of ifs
Function will be called more then many times
Such function can call such functions and they can call such functions again. Each of them will perform the same validation

回复收藏 0 原文

药祭#氼 2024-07-23 08:54:57

我想说，在 PrintAge 中检查它似乎更有意义，因为这是履行例程的合同。当然，您可以用 Debug.Assert() 代码替换空检查，以在测试时进行检查，但不能在发布时进行检查。

回复收藏 0 原文

罪#恶を代价 2024-07-23 08:54:57

你的意思是检查这两种方法？我肯定会检查 PrintAge 以及它在 Main 中是否也有意义。我认为一般来说没有明确的答案。这取决于：-）

回复收藏 0 原文

ぺ禁宫浮华殁 2024-07-23 08:54:57

我通常让空检查由我的期望控制；如果我期望某些内容为空或不确定，我会添加一个检查。否则我不会。空指针异常是最容易跟踪的问题之一，因此过多的检查会使代码膨胀。在具体的示例中，我不会检查任何内容，因为它很直观，它不为空。

回复收藏 0 原文

ペ泪落弦音 2024-07-23 08:54:57

如果实例为空，您想做什么？

我认为这取决于你提供的API & 定义契约（.net 框架类的方式）。话虽如此，如果该方法定义了传递给它的空引用情况下的预期结果，则不需要检查空值（在 main 中）。

回复收藏 0 原文

无人接听 2024-07-23 08:54:57

据我了解你的问题比你的例子所说明的更普遍。我的偏好如下：

所有可公开访问的方法都必须检查 NULL 输入并酌情抛出异常。因此，如果您正在构建一个供其他人使用的框架，请进行防御性编码。
如果您知道这是在其他地方完成的或者参数永远不会为 NULL，私有方法可以省略 NULL 检查，但一般来说，我更喜欢显式的 ArgumentNullException 而不是 NullRefereceException。

Brad Abrams 在此提供了更多信息：http://blogs。 msdn.com/brada/archive/2004/07/11/180315.aspx

回复收藏 0 原文