函数应该返回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的数据库中将没有用户信息。我会想象在这种情况下抛出异常是不合适的？另外，我的印象是异常处理会损害性能。

如果您打算指示没有可用数据，则返回null通常是最好的主意。

空对象表示已返回数据，而返回null则表示未返回任何内容。

此外，如果您尝试访问对象中的成员，则返回null将会导致null异常，这对于突出显示错误代码很有用-尝试不访问任何成员都是没有意义的。访问空对象的成员不会失败，这意味着错误可能会被发现。

这取决于哪种情况最适合您的情况。

返回null是否有意义，例如“不存在这样的用户”？

还是创建默认用户有意义？当您可以安全地假设一个用户不存在时，这才最有意义。

还是如果调用代码要求使用无效ID的用户抛出异常（例如“ FileNotFound”），是否有意义？

但是，从关注点/ SRP的角度来看，前两个更正确。从技术上讲，第一个是最正确的（但只能靠头发）-GetUserById只应负责一件事-获取用户。通过返回其他内容来处理其自己的“用户不存在”的情况可能违反了SRP。分开检查- bool DoesUserExist(id)如果您确实选择引发异常，则比较合适。

基于以下广泛的评论：如果这是API级设计问题，则此方法可能类似于“ OpenFile”或“ ReadEntireFile”。我们正在从某个存储库中“打开”用户，并从结果数据中添加对象。在这种情况下，例外可能是适当的。可能不是，但可能是。

所有方法都是可以接受的-这取决于API /应用程序的较大上下文。

我个人使用NULL。很明显，没有数据要返回。但是在某些情况下，空对象可能有用。

如果您的返回类型是一个数组，则返回一个空数组，否则返回null。

如果特定合同违约，则应该（仅）引发异常。
在您的特定示例中，基于已知ID询问UserEntity，这取决于事实（如果缺少（删除）用户）是预期情况。如果是这样，则返回，null但如果不是预期的情况，则抛出异常。
请注意，如果调用该函数，UserEntity GetUserByName(string name)则可能不会抛出该异常，但返回null。在这两种情况下，返回一个空的UserEntity都是无济于事的。

对于字符串，数组和集合，情况通常是不同的。我记得一些指导形式的MS，方法应将其接受null为“空”列表，但返回零长度而不是的集合null。字符串也一样。请注意，您可以声明空数组：int[] arr = new int[0];

这是一个业务问题，取决于是否存在具有特定Guid ID的用户是此功能的正常预期使用情况，还是异常情况会阻止应用程序成功完成此方法提供给用户的任何功能反对...

如果这是“例外”，则因为缺少具有该ID的用户将阻止应用程序成功完成其正在执行的任何功能，（例如，我们正在为已将产品运送到的客户创建发票... ），那么这种情况下应该抛出ArgumentException（或其他一些自定义异常）。

如果缺少用户可以（调用此函数的潜在正常结果之一），则返回null...。

编辑：（以解决来自亚当的评论）

如果应用程序包含多个业务流程，其中一个或多个需要用户才能成功完成，而一个或多个流程可以在没有用户的情况下成功完成，则应在调用堆栈的更远处（更靠近位置）抛出异常。需要用户的业务流程正在调用此执行线程。此方法与该点之间的方法（引发异常的位置）仅应传达不存在任何用户的信息（null，boolean，无论如何，这是实现细节）。

但是，如果应用程序中的所有进程都需要一个用户，我仍然会在此方法中引发异常...

我个人将返回null，因为这是我期望DAL /存储库层起作用的方式。

如果它不存在，请不要返回任何可以被解释为成功获取对象的东西，null在这里效果很好。

最重要的是要在DAL / Repos层上保持一致，这样您就不会对如何使用它感到困惑。

我倾向于

• return null如果当它不知道是不存在的对象ID事前是否应该存在。
• throw如果对象ID不存在，应在何时存在。

我用这三种类型的方法来区分这两种情况。第一：

Boolean TryGetSomeObjectById(Int32 id, out SomeObject o)
{
    if (InternalIdExists(id))
    {
        o = InternalGetSomeObject(id);

        return true;
    }
    else
    {
        return false;
    }
}

第二：

SomeObject FindSomeObjectById(Int32 id)
{
    SomeObject o;

    return TryGetObjectById(id, out o) ? o : null;
}

第三：

SomeObject GetSomeObjectById(Int32 id)
{
    SomeObject o;

    if (!TryGetObjectById(id, out o))
    {
        throw new SomeAppropriateException();
    }

    return o;
}

还有另一种方法涉及传递将对值进行操作的回调对象或委托。如果找不到值，则不调用回调。

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();
}

从设计的角度来看，我真的很喜欢这种方法，但是它的缺点是使呼叫站点使用了不容易支持一流功能的语言。

我们使用CSLA.NET，它认为失败的数据提取应返回“空”对象。这实际上很烦人，因为它要求检查是否obj.IsNew不是的惯例obj == null。

如前所述，空返回值将导致代码立即失败，从而减少了由空对象引起的隐身问题的可能性。

我个人认为null比较优雅。

这是一个非常常见的情况，令我感到惊讶的是，这里的人们似乎对此感到惊讶：在任何Web应用程序上，数据通常都是使用querystring参数来获取的，显然可以对它进行处理，因此要求开发人员处理“未找到”的情况。 ”。

您可以通过以下方式处理此问题：

如果（User.Exists（id））{
  this.User = User.Fetch（id）;
}其他{
  Response.Redirect（“〜/ notfound.aspx”）;
}

...但是这每次都是对数据库的额外调用，这在高流量页面上可能是个问题。鉴于：

this.User = User.Fetch（id）;

如果（this.User == null）{
  Response.Redirect（“〜/ notfound.aspx”）;
}

...只需要一个电话。

我更喜欢null，因为它与null运算符（??）兼容。

我会说返回null而不是一个空对象。

但是，您在此处提到的特定实例是按用户ID搜索用户，这是该用户的键，在这种情况下，如果找不到用户实例，我可能想抛出异常。

这是我通常遵循的规则：

• 如果在主键操作的find上没有找到结果，则抛出ObjectNotFoundException。
• 如果通过任何其他条件未在搜索结果中找到结果，则返回null。
• 如果在非关键条件下未找到可能返回多个对象的结果，则返回一个空集合。

它会根据上下文而变化，但是如果我正在寻找一个特定的对象（如您的示例），则通常将返回null；如果我正在寻找一组对象但没有一个对象，则通常返回一个空集合。

如果您在代码中犯了一个错误，并且返回null会导致null指针异常，那么越早发现它越好。如果返回一个空对象，则可以初次使用它，但是稍后可能会出错。

在没有这种用户的情况下，最好在这种情况下返回“ null”。还要使您的方法静态。

编辑：

通常，这样的方法是某些“ User”类的成员，并且无法访问其实例成员。在这种情况下，该方法应该是静态的，否则，您必须创建“ User”的实例，然后调用GetUserById方法，该方法将返回另一个“ User”实例。同意这令人困惑。但是，如果GetUserById方法是某些“ DatabaseFactory”类的成员-将其保留为实例成员没有问题。

我个人返回了该对象的默认实例。原因是我希望该方法返回零对多或零对一（取决于方法的目的）。使用这种方法，它将是任何类型的错误状态的唯一原因是，如果该方法未返回任何对象并且始终被期望（以一对多或单数返回）。

关于这是一个业务领域问题的假设-我只是从等式的那一侧看不到它。返回类型的规范化是一个有效的应用程序体系结构问题。至少，它是编码实践中标准化的主题。我怀疑是否有业务用户会说“在方案X中，请给他们一个空值”。

在我们的业务对象中，我们有两个主要的Get方法：

为了使事情在上下文中简单，或者您怀疑它们是：

// Returns null if user does not exist
public UserEntity GetUserById(Guid userId)
{
}

// Returns a New User if user does not exist
public UserEntity GetNewOrExistingUserById(Guid userId)
{
}

获取特定实体时使用第一种方法，而在网页上添加或编辑实体时专门使用第二种方法。

这使我们能够在使用它们的环境中拥有两全其美的优势。

我是法国IT专业的学生，​​请原谅我可怜的英语。在我们的类中，我们被告知这样的方法永远不要返回null或空对象。该方法的用户应该在尝试获取对象之前先检查其寻找的对象是否存在。

使用Java，要求我们assert exists(object) : "You shouldn't try to access an object that doesn't exist";在任何可能返回null的方法的开头添加一个，以表示“前提”（我不知道英语中的单词是什么）。

IMO这确实不容易使用，但这就是我在使用，等待更好的东西。

如果找不到用户的情况经常出现，并且您希望根据情况（有时抛出异常，有时替换空用户）以各种方式处理该问题，那么您也可以使用接近F＃Option或Haskell Maybe类型的值，将“无价值”情况与“发现某物！”明确区分开来。数据库访问代码如下所示：

public Option<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 Option<UserEntity>.Nothing; 
 else
    return Option.Just(existingUserEntity);
}

并像这样使用：

Option<UserEntity> result = GetUserById(...);
if (result.IsNothing()) {
    // deal with it
} else {
    UserEntity value = result.GetValue();
}

不幸的是，每个人似乎都推出了自己的这种类型。

我通常返回null。它提供了一种快速简便的机制来检测是否发生了一些错误，而不会抛出异常，并且在整个地方都进行了大量尝试/捕获。

对于集合类型，我将返回一个空集合，对于所有其他类型，我更喜欢使用NullObject模式返回一个对象，该对象实现了与返回类型相同的接口。有关模式的详细信息，请查看链接文本

使用NullObject模式，它将是：-

public UserEntity GetUserById(Guid userId)

{//想像一下这里的代码来访问数据库.....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return new NullUserEntity(); //Should I be doing this here instead? return new UserEntity();  
 else
    return existingUserEntity;

}

class NullUserEntity: IUserEntity { public string getFirstName(){ return ""; } ...} 

说得更通俗一点

例外情况适用于特殊情况

如果此方法是纯数据访问层，那么我会说，给定一个包含在select语句中的参数，它将期望我找不到从中构建对象的任何行，因此返回null将是可以接受的是数据访问逻辑。

在另一方面，如果我希望我的参数来反映一个主键，我应该只得到一个行回来，如果我得到了不止一回我会抛出异常。0可以返回null，2不能。

现在，如果我有一些登录代码根据LDAP提供程序进行了检查，然后针对数据库进行了检查以获取更多详细信息，并且我希望这些信息始终保持同步，那么我可能会抛出异常。正如其他人所说，这是业务规则。

现在，我要说这是一般规则。有时候您可能想打破它。但是，我的经验和对C＃（很多）和Java（有点）的实验告诉我，处理异常要比通过条件逻辑处理可预测的问题要贵得多。在某些情况下，我所说的价格要贵2到3个数量级。因此，如果您的代码有可能最终陷入循环，那么我建议您返回null并对其进行测试。

原谅我的伪PHP /代码。

我认为这实际上取决于结果的预期用途。

如果打算编辑/修改返回值并保存它，则返回一个空对象。这样，您可以使用相同的函数在新对象或现有对象上填充数据。

假设我有一个函数，该函数需要一个主键和一个数据数组，用数据填充行，然后将结果记录保存到db。由于我打算以任何一种方式用我的数据填充对象，因此从吸气剂中回收空对象可能是一个巨大的优势。这样，无论哪种情况，我都可以执行相同的操作。无论如何，都可以使用getter函数的结果。

例：

function saveTheRow($prim_key, $data) {
    $row = getRowByPrimKey($prim_key);

    // Populate the data here

    $row->save();
}

在这里，我们可以看到相同的一系列操作操作了该类型的所有记录。

但是，如果返回值的最终目的是读取数据并对其进行处理，那么我将返回null。这样，我可以非常迅速地确定是否没有数据返回，并向用户显示适当的消息。

通常，我会在获取数据的函数中捕获异常（这样我就可以记录错误消息等），然后直接从捕获中返回null。对于最终用户来说，问题通常无关紧要，所以我发现最好将错误日志记录/处理直接封装在获取数据的函数中。如果您要在任何大型公司中维护共享的代码库，这将特别有益，因为您甚至可以在最懒惰的程序员上强制进行正确的错误记录/处理。

例：

function displayData($row_id) {
    // Logging of the error would happen in this function
    $row = getRow($row_id);
    if($row === null) {
        // Handle the error here
    }

    // Do stuff here with data
}

function getRow($row_id) {
 $row = null;
 try{
     if(!$db->connected()) {
   throw excpetion("Couldn't Connect");
  }

  $result = $db->query($some_query_using_row_id);

  if(count($result) == 0 ) {
   throw new exception("Couldn't find a record!");
  }

  $row = $db->nextRow();

 } catch (db_exception) {
  //Log db conn error, alert admin, etc...
  return null; // This way I know that null means an error occurred
 }
 return $row;
}

这是我的一般规则。到目前为止效果很好。

有趣的问题，我认为没有“正确”的答案，因为它始终取决于代码的责任。您的方法是否知道没有找到的数据是否有问题？在大多数情况下，答案是“否”，这就是为什么返回null并让呼叫者处理情况是完美的原因。

区分投掷方法和返回null的方法的一种好方法也许是在团队中找到一个约定：如果说什么都“得到”，那么如果什么也没得到，就应该抛出异常。可能返回null的方法可以用不同的名称命名，也许用“ Find ...”代替。

如果返回的对象是可以迭代的对象，那么我将返回一个空对象，这样就不必先测试null。

例：

bool IsAdministrator(User user)
{
    var groupsOfUser = GetGroupsOfUser(user);

    // This foreach would cause a run time exception if groupsOfUser is null.
    foreach (var groupOfUser in groupsOfUser) 
    {
        if (groupOfUser.Name == "Administrators")
        {
            return true;
        }
    }

    return false;
}

我不希望从任何方法中返回null，而是使用Option函数类型。无法返回结果的方法将返回一个空的Option，而不是null。

同样，此类无法返回结果的方法应通过其名称来表明这一点。我通常将Try或TryGet或TryFind放在方法名称的开头，以指示它可能返回空结果（例如TryFindCustomer，TryLoadFile等）。

这使调用者可以对结果应用不同的技术，例如集合流水线（请​​参阅Martin Fowler的Collection Pipeline）。

这是另一个示例，其中返回Option而不是null可以减少代码复杂度：如何降低循环复杂度：Option功能类型

需要绞尽脑汁：假设某些建议，我的DAL为GetPersonByID返回NULL。如果我的BLL（比较稀薄）收到NULL，应该怎么办？传递该NULL并让最终用户担心它（在这种情况下，是ASP.Net页）？让BLL抛出异常怎么样？

BLL可能正在由ASP.Net和Win App或其他类库使用-我认为期望最终消费者从本质上“知道”方法GetPersonByID返回null是不公平的（除非使用null类型，我想）。

我的看法（价值）是，如果什么也没找到，我的DAL将返回NULL。对于某些对象，这没关系-可能是0：很多事物列表，所以没有任何事物是可以的（例如，最喜欢的书的列表）。在这种情况下，我的BLL返回一个空列表。对于大多数单个实体的事物（例如用户，帐户，发票），如果我没有，那肯定是一个问题，并且会引发代价高昂的异常。但是，将异常视为由应用程序先前提供的唯一标识符来检索用户应该总是返回一个用户，该异常是“适当的”异常，这是例外。BLL的最终用户（ASP.Net，f'rinstance）只希望事情是笨拙的，因此将使用未处理的异常处理程序，而不是将对GetPersonByID的每个调用都包装在try-catch块中。

如果我的方法存在明显问题，请告诉我，因为我一直热衷于学习。正如其他发布者所说的那样，例外是代价高昂的事情，“先检查”方法是好的，但是例外应仅是例外。

我喜欢这篇文章，对于“取决于情况”的场景有很多好的建议：-)

为了代码库的健康，我认为函数不应返回null。我可以想到一些原因：

将有大量的保护条款处理空引用if (f() != null)。

什么是null，是公认的答案还是问题？null是否为特定对象的有效状态？（假设您是该代码的客户端）。我的意思是所有引用类型都可以为null，但是应该吗？

有null游逛几乎总是给从时间一些意想不到的NullRef例外时间你的代码库的增长。

有一些解决方案，tester-doer pattern或option type从功能编程中实现。

我对（在整个网络上）答案的数量感到困惑，他们说您需要两种方法：“ IsItThere（）”方法和“ GetItForMe（）”方法，因此这导致了竞争状况。返回null，将其分配给变量并在一次测试中检查变量是否为Null的函数有什么问题？我以前的C代码充满了

if（NULL！=（variable = function（arguments ...）））{

因此，您可以在一个变量中获得值（或null），并立即获得所有结果。这个习语被遗忘了吗？为什么？

我同意这里的大多数帖子，倾向于null。

我的理由是，生成具有不可为空的属性的空对象可能会导致错误。例如，具有int ID属性的实体的初始值为ID = 0，这是一个完全有效的值。如果在某种情况下该对象被保存到数据库中，那将是一件坏事。

对于任何带有迭代器的东西，我将始终使用空集合。就像是

foreach (var eachValue in collection ?? new List<Type>(0))

我认为代码有异味。集合属性永远不能为null。

边缘情况是String。许多人说，String.IsNullOrEmpty这并不是必须的，但是您不能总是区分空字符串和null。此外，某些数据库系统（Oracle）根本不会在它们之间进行区分（''存储为DBNULL），因此您不得不同等地处理它们。原因是，大多数字符串值要么来自用户输入，要么来自外部系统，而文本框和大多数交换格式都没有针对''和的不同表示形式null。因此，即使用户想要删除一个值，他也只能清除输入控件。同样nvarchar，如果您的DBMS不是oracle，则可空数据库字段和不可空数据库字段之间的区别也值得怀疑-强制字段允许''很奇怪，您的用户界面绝对不允许这样做，因此您的约束无法映射。因此，我认为这里的答案是，始终平等地对待它们。

关于有关异常和性能的问题：如果抛出无法在程序逻辑中完全处理的异常，则必须在某个时候中止程序正在执行的任何操作，并要求用户重做他所做的任何事情。在那种情况下，a的性能损失catch实际上是您最省心的事情-必须询问用户房间里的大象（这意味着重新渲染整个UI或通过Internet发送一些HTML）。因此，如果您不遵循“ 带异常的程序流 ”的反模式，请不要打扰，只要有意义就扔一个。即使在极端情况下，例如“ Validation Exception”，性能也不是问题，因为在任何情况下都必须再次询问用户。

一个异步TryGet模式：

对于同步方法，我相信@Johann Gerell的 答案是在所有情况下都可以使用的模式。

但是，带有out参数的TryGet模式不适用于Async方法。

使用C＃7的元组文字，您现在可以执行以下操作：

async Task<(bool success, SomeObject o)> TryGetSomeObjectByIdAsync(Int32 id)
{
    if (InternalIdExists(id))
    {
        o = await InternalGetSomeObjectAsync(id);

        return (true, o);
    }
    else
    {
        return (false, default(SomeObject));
    }
}