从函数返回数据的最佳实践是什么?是返回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的用户信息。我认为在这种情况下抛出异常是不合适的??另外，我的印象是异常处理会损害性能。
当前回答
还有一种方法涉及传入一个回调对象或委托，它将对值进行操作。如果没有找到值，则不调用回调。
public void GetUserById(Guid id, UserCallback callback)
{
// Lookup user
if (userFound)
callback(userEntity); // or callback.Call(userEntity);
}
当您希望避免在整个代码中进行空检查时，以及当找不到值并不是错误时，这种方法非常有效。如果需要任何特殊处理，还可以在没有找到对象时提供回调。
public void GetUserById(Guid id, UserCallback callback, NotFoundCallback notFound)
{
// Lookup user
if (userFound)
callback(userEntity); // or callback.Call(userEntity);
else
notFound(); // or notFound.Call();
}
使用单个对象的相同方法如下所示:
public void GetUserById(Guid id, UserCallback callback)
{
// Lookup user
if (userFound)
callback.Found(userEntity);
else
callback.NotFound();
}
从设计的角度来看，我真的很喜欢这种方法，但是它的缺点是在不支持第一类函数的语言中使调用站点变得更庞大。
其他回答
我更喜欢null，因为它与空合并操作符(??)兼容。
我是一名法国IT专业的学生，所以请原谅我的英语不好。在我们的类中，我们被告知这样的方法永远不应该返回null，也不应该返回空对象。这种方法的用户应该在尝试获取对象之前首先检查他正在寻找的对象是否存在。
使用Java，我们被要求添加一个断言exists(object):“您不应该尝试访问一个不存在的对象”;在任何可能返回null的方法的开头，以表达“先决条件”(我不知道英文单词是什么)。
在我看来，这真的不容易使用，但这就是我正在使用的，等待更好的东西。
我不喜欢从任何方法返回null，而是使用Option函数类型。不返回结果的方法返回空选项，而不是null。
而且，不能返回结果的方法应该通过名称来指明。我通常把Try或TryGet或TryFind放在方法名称的开头，以表明它可能返回一个空结果(例如TryFindCustomer, TryLoadFile等)。
这让调用者可以对结果应用不同的技术，比如收集管道(参见Martin Fowler的收集管道)。
下面是另一个使用返回Option而不是null来降低代码复杂性的示例:如何降低圈复杂度:选项函数类型
更多的肉要磨:让我们说我的DAL返回一个NULL的GetPersonByID，正如一些建议。我的(相当薄)BLL应该做什么，如果它收到一个NULL?传递NULL，并让最终消费者担心它(在这种情况下，一个ASP。网络页面)?让BLL抛出一个异常怎么样?
BLL可能正在被ASP使用。Net和Win App，或者其他类库——我认为期望最终消费者本质上“知道”GetPersonByID方法返回null是不公平的(除非使用空类型，我猜)。
My take (for what it's worth) is that my DAL returns NULL if nothing is found. FOR SOME OBJECTS, that's ok - it could be a 0:many list of things, so not having any things is fine (e.g. a list of favourite books). In this case, my BLL returns an empty list. For most single entity things (e.g. user, account, invoice) if I don't have one, then that's definitely a problem and a throw a costly exception. However, seeing as retrieving a user by a unique identifier that's been previously given by the application should always return a user, the exception is a "proper" exception, as in it's exceptional. The end consumer of the BLL (ASP.Net, f'rinstance) only ever expects things to be hunky-dory, so an Unhandled Exception Handler will be used instead of wrapping every single call to GetPersonByID in a try - catch block.
如果我的方法有明显的问题，请让我知道，因为我总是渴望学习。正如其他帖子所说，异常是代价高昂的事情，“先检查”的方法是好的，但异常应该只是例外。
我很喜欢这篇文章，很多关于“视情况而定”的好建议:-)
为了代码库的健康，我认为函数不应该返回null。我能想到几个原因:
将有大量的保护子句处理空引用if (f() != null)。
什么是空，它是一个公认的答案还是一个问题?null是特定对象的有效状态吗?(假设您是代码的客户端)。我的意思是所有引用类型都可以为空，但是它们应该为空吗?
当你的代码库不断增长时，使用null几乎总是会不时地产生一些意想不到的NullRef异常。
有一些解决方案，测试者-执行者模式或从函数式编程实现选项类型。
