问这个问题表明你可能对错误处理策略感兴趣。如何以及在哪里处理错误是一个普遍存在的体系结构问题。有几种方法可以做到这一点。

我最喜欢的是：允许异常在“主循环”或其他具有适当职责的函数中波动-捕获它们。检查错误情况并适当处理它们可以被视为一项专门的责任。

当然，也要看看面向方面编程——它们有很好的方法将if（o==null）handleNull（）插入到字节码中。

总而言之，避免声明

if (object != null) {
    ....
}

由于java7，您可以使用Objects方法：Objects.isNull（对象）Objects.nonNull（对象）Objects.requireOnNull（对象）Objects.equals（object1，object2）从java8开始，您可以使用Optional类（何时使用）

object.ifPresent（obj->…）；java 8

object.ifPresentOrElse（对象->…，（）->…）；java 9

依靠方法契约（JSR305）并使用FindBugs。用annotations@javax.annotation.Nullable和@javax.annotation.Nonnnual标记代码。还提供了前提条件。前提条件.checkNotNull（对象）；在特殊情况下（例如字符串和集合），可以使用apachecommons（或Google guava）实用程序方法：

公共静态布尔isEmpty（CharSequence cs）//apache CollectionUtils公共静态布尔isEmpty（集合coll）//apacheStringUtils公共静态布尔isEmpty（Map Map）//apache MapUtils公共静态布尔isNullOrEmpty（@Nullable String字符串）//Guava字符串

当您需要在null时分配默认值时，请使用apachecommons-lang

公共静态对象defaultIfNull（对象对象，对象defaultValue）

我喜欢Nat Pryce的文章。以下是链接：

用多态调度避免空值避免使用“告诉，不要问”风格的null

在文章中，还有一个指向Java Maybe Type的Git存储库的链接，我觉得这很有趣，但我不认为单独使用它会降低检查代码膨胀。在互联网上做了一些研究之后，我想主要通过仔细设计可以减少空码膨胀。

Java中常见的“问题”确实存在。

首先，我的想法是：

我认为，当传递NULL时，如果NULL不是有效值，“吃掉”某些东西是不好的。如果您退出方法时没有出现某种错误，那么这意味着您的方法中没有任何错误，这是不正确的。在这种情况下，您可能会返回null，在接收方法中，您再次检查null，并且它永远不会结束，结果是“if！=null”等。。

因此，IMHO，null必须是阻止进一步执行的关键错误（即，null不是有效值）。

我解决这个问题的方法是：

首先，我遵循以下惯例：

所有公共方法/API始终检查其参数是否为空所有私有方法都不检查null，因为它们是受控制的方法（如果上面没有处理null指针异常，就让它终止）唯一不检查null的其他方法是实用程序方法。他们是公开的，但如果你出于某种原因打电话给他们，你知道你通过了哪些参数。这就像试图在水壶里烧水而不提供水。。。

最后，在代码中，public方法的第一行如下所示：

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

注意，addParam（）返回self，这样您就可以添加更多的参数来检查。

如果任何参数为空，方法validate（）将抛出checked ValidationException（checked或unchecked更多是设计/品味问题，但我的ValidationException已选中）。

void validate() throws ValidationException;

例如，如果“计划”为空，则消息将包含以下文本：

“参数[plans]遇到非法参数值null”

正如您所看到的，用户消息需要addParam（）方法中的第二个值（字符串），因为即使有反射（无论如何都不是本文的主题…），也无法轻松检测传入的变量名。

是的，我们知道，在这一行之外，我们将不再遇到空值，因此我们只需安全地调用这些对象上的方法。

这样，代码就干净、易于维护和可读。

哇，当我们有57种不同的方式来推荐NullObject模式时，我几乎不想再加一个答案，但我想，一些对这个问题感兴趣的人可能想知道，有人提议为Java7添加“空安全处理”，这是一种精简的语法，如果不等于空逻辑的话。

Alex Miller给出的示例如下：

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

这个表示仅在左标识符不为空时取消引用，否则将表达式的其余部分求值为空。一些人，如Java Pose成员迪克·沃尔（Dick Wall）和德文郡的选民，真的很喜欢这个提议，但也有人反对，理由是它实际上会鼓励更多地使用null作为前哨值。

更新：在Project Coin下提交了一份关于Java 7中空安全运算符的官方提案。语法与上面的示例稍有不同，但概念相同。

更新：空安全运营商提议未纳入Project Coin。因此，您不会在Java7中看到这种语法。

避免不必要的空检查的方法很简单：

您需要知道哪些变量可以为空，哪些变量不能为空，并且您需要对给定变量属于哪一类有信心。

但是，尽管它可以说得很简单，但实现它却很困难。关键在于自信的部分，因为你如何确定变量不能为空？

对此没有快速的解决方法，但这里有一些提示：

干净的代码。能够推理一段代码的行为最重要的一点是，它是以易于理解的方式编写的。根据变量所代表的内容命名变量，根据它们所做的内容命名方法，应用单一责任原则（SOLID中的S：http://en.wikipedia.org/wiki/SOLID_（object-oriented_design），这意味着每一段代码都应该有一个单独的责任，并且不做任何其他事情）。一旦你的代码是干净的，那么你就更容易理解它，也更容易理解多个代码层。对于杂乱的代码，试图理解一个方法的作用可能会让你忘记当初为什么要读这个方法。（提示：阅读罗伯特·C·马丁的《清洁代码》）避免返回空值。如果空值会使程序无法正常运行，请改为抛出异常（确保添加适当的错误处理）。返回空值可能是可接受的情况，例如，尝试从数据库中获取对象。在这些情况下，编写处理空值的代码，并在您的耳朵后面记下，这里有可能返回空值的内容。处理返回的null值，使其尽可能接近返回null的方法的调用方（不要盲目地将其传递回调用链）永远不要将显式空值作为参数传递（至少不要跨类传递）。如果您曾经处于传递空参数是唯一选项的位置，那么创建一个不包含此参数的新方法是一种方法。验证您的输入！确定应用程序的“入口点”。它们可以从Web服务、REST服务、远程EJB类、控制器等所有内容。对于这些入口点中的每个方法，问问自己：“如果此参数为空，此方法是否正确执行？”如果答案为否，请添加Validate.notNull（someParam，“当someParam为空时无法运行！”）；。如果缺少必需的参数，这将引发IllegalArgumentException。在入口点进行这种类型的验证的好处是，您可以很容易地在从入口点执行的代码中假设该变量永远不会为空！此外，如果这失败了，在入口点，调试会比代码深处出现NullPointerException要容易得多，因为这样的失败只能意味着一件事：客户端没有向您发送所有必需的信息。在大多数情况下，您希望验证所有输入参数，如果您发现自己处于需要允许大量空值的位置，这可能是接口设计不良的标志，需要进行重构/添加以满足客户机的需要。使用集合时，返回一个空集合而不是空集合！使用数据库时，请使用非空约束。这样，您就知道从数据库中读取的值不能为空，并且不必检查它。构造代码并坚持执行。这样做可以让您对代码的行为做出假设，例如，如果应用程序的所有输入都经过验证，那么您可以假设这些值永远不会为空。如果您还没有这样做，请编写代码的自动测试。通过编写测试，您将对代码进行推理，并且您也将更加确信它确实做到了它应该做的事情。此外，自动化测试通过让您立即知道这段代码没有做以前的事情来防止重构过程中的错误。

当然，您仍然需要进行空检查，但它可以降到最低限度（即，知道您可能会得到空值，而不是到处都是空值）。当谈到空检查时，我实际上更喜欢使用三元运算符（但要小心使用，当您开始嵌套它们时，它们会变得非常混乱）

public String nullSafeToString(final Object o) {
    return o != null ? o.toString() : "null";
}