例外应该是例外。如果返回null是有效的，则返回null。

如果对于客户端代码来说，知道已找到和未找到之间的区别很重要，并且这应该是一个例程行为，那么最好返回null。然后客户端代码可以决定要做什么。

如果您总是希望找到一个值，那么如果缺少该值则抛出异常。这个例外意味着有问题。

如果该值可以缺失或存在，并且两者都对应用程序逻辑有效，则返回null。

更重要的是:在代码的其他地方做什么?一致性很重要。

这里还有一些建议。

如果返回一个集合，避免返回null，返回一个空集合，这使得枚举更容易处理，而不需要先进行空检查。

一些. net API使用thrownOnError参数的模式，如果对象没有找到，调用者可以选择是否真的是异常情况。类型。GetType就是一个例子。BCL的另一个常见模式是TryGet模式，其中返回一个布尔值，并通过输出参数传递值。

在某些情况下，您还可以考虑Null Object模式，它可以是默认的，也可以是没有行为的版本。关键是避免在整个代码库中进行空检查。更多信息请参见这里链接

在数据层代码中，我有时使用以下代码，允许调用者决定“对象未找到”是否意味着发生了错误。

DataType GetObject(DBConnection conn, string id, bool throwOnNotFound) {
    DataType retval = ... // find object in database
    if (retval != null || ! throwOnNotFound) {
        return retval;
    } else {
        throw new NoRowsFoundException("DataType object with id {id} not found in database");
    }
}

DataType GetObject(DBConnection conn, string id) {
    return GetObject(conn, id, true);
} 

抛出异常的好处:

Cleaner control flow in your calling code. Checking for null injects a conditional branch which is natively handled by try/catch. Checking for null doesn't indicate what it is you're checking for - are you checking for null because you're looking for an error you're expecting, or are you checking for null so you don't pass it further on downchain? Removes ambiguity of what "null" means. Is null representative of an error or is null what is actually stored in the value? Hard to say when you only have one thing to base that determination off of. Improved consistency between method behavior in an application. Exceptions are typically exposed in method signatures, so you're more able to understand what edge cases the methods in an application account for, and what information your application can react to in a predictable manner.

有关更多示例的解释，请参见:http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/