有趣的问题，我认为没有“正确”的答案，因为它总是取决于你的代码的职责。您的方法是否知道没有找到的数据是否存在问题?在大多数情况下，答案是“不”，这就是为什么返回null并让调用者处理他的情况是完美的。

也许区分抛出方法和返回null方法的一个好方法是在您的团队中找到一个约定:如果没有得到任何东西，表示它们“得到”某些东西的方法应该抛出异常。可能返回null的方法可以以不同的方式命名，可能是“Find…”。

我同意这里的大多数帖子，它们趋向于零。

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

对于任何带有迭代器的东西，我总是使用空集合。类似的

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

在我看来是代码的味道。集合属性永远不应该为空。

An edge case is String. Many people say, String.IsNullOrEmpty isn't really necessary, but you cannot always distinguish between an empty string and null. Furthermore, some database systems (Oracle) won't distinguish between them at all ('' gets stored as DBNULL), so you're forced to handle them equally. The reason for that is, most string values either come from user input or from external systems, while neither textboxes nor most exchange formats have different representations for '' and null. So even if the user wants to remove a value, he cannot do anything more than clearing the input control. Also the distinction of nullable and non-nullable nvarchar database fields is more than questionable, if your DBMS is not oracle - a mandatory field that allows '' is weird, your UI would never allow this, so your constraints do not map. So the answer here, in my opinion is, handle them equally, always.

Concerning your question regarding exceptions and performance: If you throw an exception which you cannot handle completely in your program logic, you have to abort, at some point, whatever your program is doing, and ask the user to redo whatever he just did. In that case, the performance penalty of a catch is really the least of your worries - having to ask the user is the elephant in the room (which means re-rendering the whole UI, or sending some HTML through the internet). So if you don't follow the anti-pattern of "Program Flow with Exceptions", don't bother, just throw one if it makes sense. Even in borderline cases, such as "Validation Exception", performance is really not an issue, since you have to ask the user again, in any case.

我更喜欢null，因为它与空合并操作符(??)兼容。

在这种情况下，如果没有这样的用户，则最好返回“null”。还要使你的方法是静态的。

编辑:

通常这样的方法是一些“User”类的成员，不能访问它的实例成员。在这种情况下，方法应该是静态的，否则你必须创建一个“User”的实例，然后调用GetUserById方法，该方法将返回另一个“User”实例。我同意这很令人困惑。但是如果GetUserById方法是某个“DatabaseFactory”类的成员，那么将它作为实例成员是没有问题的。

我不喜欢从任何方法返回null，而是使用Option函数类型。不返回结果的方法返回空选项，而不是null。

而且，不能返回结果的方法应该通过名称来指明。我通常把Try或TryGet或TryFind放在方法名称的开头，以表明它可能返回一个空结果(例如TryFindCustomer, TryLoadFile等)。

这让调用者可以对结果应用不同的技术，比如收集管道(参见Martin Fowler的收集管道)。

下面是另一个使用返回Option而不是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 ""; } ...}