NullReferenceException 是谁的错？

发布于 2024-09-04 05:21:05 字数 979 浏览 10 评论 0原文

我目前正在开发一个通过属性公开内部列表的类。该清单应当并且可以修改。问题是，内部列表中的条目可以从类外部设置为 null。

我的代码实际上如下所示：

class ClassWithList
{
    List<object> _list = new List<object>();

    // get accessor, which however returns the reference to the list,
    // therefore the list can be modified (this is intended)
    public List<object> Data
    {
        get
        {
            return _list;
        }
    }

    private void doSomeWorkWithTheList()
    {
        foreach(object obj in _list)
            // do some work with the objects in the list without checking for null.
    }
}

所以现在在 doSomeWorkWithTheList() 中，我总是可以检查当前列表条目是否为空，或者我可以假设使用此类的人没有将条目设置为空的好主意。

所以最终问题是：在这种情况下，NullReferenceException 是谁的错？是类开发人员没有检查所有内容是否为 null 的错误（这通常会使代码 - 不仅在此类中 - 更加复杂），还是此类用户的错误，因为将 List 条目设置为 null 不会真的有道理吗？除非在一些非常特殊的情况下，我通常不会检查 null 值。这是一种糟糕的风格还是事实上的标准/实践标准？

我知道这个问题可能没有最终的答案，我只是缺少足够的经验来处理此类事情，因此想知道其他开发人员对此类情况的看法，并想听听在检查 null （或不）方面实际做了什么。

原文

I'm currently working on a class which exposes an internal List through a property. The List shall and can be modified. The problem is, entries in the internal list could be set to null from outside the class.

My code actually looks like this:

class ClassWithList
{
    List<object> _list = new List<object>();

    // get accessor, which however returns the reference to the list,
    // therefore the list can be modified (this is intended)
    public List<object> Data
    {
        get
        {
            return _list;
        }
    }

    private void doSomeWorkWithTheList()
    {
        foreach(object obj in _list)
            // do some work with the objects in the list without checking for null.
    }
}

So now in the doSomeWorkWithTheList() I could always check whether the current list entry is null or I could just asume that the person using this class doesn't have the great idea to set entries to null.

So finally the questions end up in: Whose fault is a NullReferenceException in this case? Is it the fault of the class developer not checking everything for null (which would make code generally - not only in this class - more complex) or is it the fault of the user of this class, as setting a List entry to null doesn't really make sense? I'd tend to generally not check values for null except in some really special cases. Is this a bad style or de facto standard / standard in praxis?

I know there's probably no ultimate answer for this, I'm just missing enough experience for such thing and therefore wondering what other developers think about such cases and want to hear what's done in reality about checking null (or not).

分享到QQ

分享到微博

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

发布评论

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

嘦怹 2024-09-11 05:21:05

如果公开该列表，则允许类的用户随意添加 null 引用。
如果您允许用户随意添加 null 引用，则您的类需要为列表中的 null 引用做好准备。

private void doSomeWorkWithTheList()
{
    foreach(object obj in _list)
        if (obj != null)
           // do some work with the object
}

如果您不喜欢这样，请不要公开列表（应该公开为 IList 顺便说一句），而是返回一个不允许 null< 的类似列表的集合/code> 要添加的引用。

If you expose the list, you allow the user of your class to add null references at will.
If you allow users to add null references at will, your class needs to be prepared for null references in the list.

private void doSomeWorkWithTheList()
{
    foreach(object obj in _list)
        if (obj != null)
           // do some work with the object
}

If you don't like that, don't expose the list (which should be exposed as IList<T> btw) but return a list-like collection that doesn't allow null references to be added.

回复收藏 0 原文

停顿的约定 2024-09-11 05:21:05

很抱歉直言不讳，但如果你的代码不优雅地失败了，那是你的错。如果您的代码的其余部分有此要求，您封装该列表并公开一个空检查添加方法怎么样？也许您的类可以实现IList，并在内部存储您要处理的列表 - 然后在Add方法中，您只需抛出NullArgumentException > 或忽略 null 并继续...