抛出异常的好处:

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/

我只是想概括一下之前提到的选项，并添加一些新的选项:

返回null 抛出异常 使用空对象模式 为您的方法提供一个布尔参数，以便调用者可以选择是否希望您抛出异常 提供一个额外的参数，以便调用者可以设置一个值，如果没有找到值，则返回该值

或者你可以把这些选项结合起来:

提供getter的多个重载版本，以便调用者可以决定采用哪种方式。在大多数情况下，只有第一个有搜索算法的实现，其他的只是围绕着第一个:

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

即使您选择只提供一个实现，您也可能希望使用这样的命名约定来阐明您的契约，并且它有助于您决定添加其他实现。

你不应该过度使用它，但它可能是有帮助的，特别是当你编写一个helper类时，你将在数百个不同的应用程序中使用许多不同的错误处理约定。

如果方法返回一个集合，则返回一个空集合(如上所述)。但请不要收钱。EMPTY_LIST或类似的!(以Java为例)

如果该方法检索单个对象，则您有一些选项。

If the method should always find the result and it's a real exception case not to find the object, then you should throw an exception (in Java: please an unchecked Exception) (Java only) If you can tolerate that the method throws a checked exception, throw a project specific ObjectNotFoundException or the like. In this case the compiler says you if you forget to handle the exception. (This is my preferred handling of not found things in Java.) If you say it's really ok, if the object is not found and your Method name is like findBookForAuthorOrReturnNull(..), then you can return null. In this case it is strongly recomminded to use some sort of static check or compiler check, wich prevents dereferencing of the result without a null check. In case of Java it can be eg. FindBugs (see DefaultAnnotation at http://findbugs.sourceforge.net/manual/annotations.html) or IntelliJ-Checking.

如果决定返回null，请小心。如果你不是项目中唯一的程序员，你会在运行时得到nullpointerexception(在Java或其他语言中)!所以不要返回在编译时没有检查的空值。

这取决于你的方法。如果你的方法应该总是返回一个有效的对象，但却没有找到，那么抛出异常就是正确的方法。如果该方法只是返回一个可能存在也可能不存在的对象(比如联系人的图像)，则不应该引发错误。

你可能还想公开一个返回布尔值true/false的方法，如果这个方法实际上会返回一个对象，这样你就不必a)检查null或b)捕捉异常

不幸的是，JDK是不一致的，如果你试图访问资源包中不存在的键，你会得到not found异常，当你从map请求值时，如果它不存在，你会得到null。因此，我将获胜者答案更改为以下内容，如果找到的值可以为null，则在未找到时引发异常，否则返回null。所以遵循规则，只有一个例外，如果你需要知道为什么没有找到值，那么总是抛出异常，或者。

通常它应该返回null。调用该方法的代码应该决定是抛出异常还是尝试其他操作。