函数应该返回null还是空对象?

从函数返回数据时的最佳实践是什么。返回Null还是空对象更好?又为什么一个要比另一个做呢?


考虑一下:


public UserEntity GetUserById(Guid userId)

{

     //Imagine some code here to access database.....


     //Check if data was returned and return a null if none found

     if (!DataExists)

        return null; 

        //Should I be doing this here instead? 

        //return new UserEntity();  

     else

        return existingUserEntity;

}

让我们假装将有此计划,将有与该GUID数据库中没有用户信息的有效案例。我可以想象在这种情况下抛出异常是不合适的?另外,我的印象是异常处理会损害性能。


慕哥6287543
浏览 855回答 3
3回答

烙印99

返回null通常是最好的主意,如果你打算表示没有数据可用。一个空的对象意味着数据已经返回,而返回null清楚地表明,什么也没有返回。此外,如果您尝试访问对象中的成员,则返回null会导致null异常,这对于突出显示错误代码很有用-尝试不访问任何成员都是没有意义的。访问空对象的成员不会失败,这意味着错误可能会被发现。

料青山看我应如是

这取决于哪种情况最适合您的情况。是否有意义返回空值,例如:“没有这样的用户存在”?还是创建默认用户有意义?这是很有道理的,当你可以安全地假设,如果用户不存在,调用代码打算为一个,当他们要求它存在。或者是否有意义抛出一个异常(一拉“FileNotFound”)如果调用代码是要求苛刻的用户使用无效的ID?但是,从关注点/ SRP的角度来看,前两个更正确。从技术上讲,第一个是最正确的(但仅凭一根头发)-GetUserById仅应负责一件事-获取用户。通过返回其他内容来处理自己的“用户不存在”的情况可能违反了SRP。分开检查- bool DoesUserExist(id)如果您确实选择引发异常,则比较合适。基于下面的大量评论:如果这是API级设计问题,则此方法可能类似于“ OpenFile”或“ ReadEntireFile”。我们正在从某个存储库“打开”用户,并从结果数据中添加对象。在这种情况下,例外可能是适当的。可能不是,但可能是。所有方法都是可以接受的-这取决于API /应用程序的较大上下文。

繁华开满天机

如果特定合同违约,则应该(仅)引发异常。在您的特定示例中,基于已知ID询问UserEntity,这取决于事实(如果缺少(删除)用户)是预期情况。如果是这样,则返回,null但是如果不是预期的情况,则抛出异常。请注意,如果调用该函数,UserEntity GetUserByName(string name)则可能不会抛出该异常,但返回null。在这两种情况下,返回一个空的UserEntity都是无济于事的。对于字符串,数组和集合,情况通常是不同的。我记得一些准则形式的MS,方法应将其接受null为“空”列表,但返回零长度而不是的集合null。字符串也一样。请注意,您可以声明空数组:int[] arr = new int[0];
打开App,查看更多内容
随时随地看视频慕课网APP