Java中处理第三方库SomeCustomException时，关于e.getMessage()空值检查的疑问与优化需求

嗨，我来帮你拆解这些问题：

1. 这个构造是否正确？ #

整体逻辑方向是对的，但有个关键笔误必须修正：你代码里的第二个条件用了&（按位与），而非&&（短路与）。&不会触发短路判断，哪怕前面e.getMessage() != null为false，它还是会执行后面的e.getMessage().contains("BOOM")，这时候直接就会抛出NullPointerException！把&改成&&后，这套空安全检查的逻辑就是完全正确的——毕竟第三方库的实现我们完全无法控制，必须防住所有可能的null场景。

2. 能不能避免这些多重检查？有没有getMessage()不会为null的保证？ #

很遗憾，没有绝对的保证。Java官方的Throwable类（所有异常的父类）的getMessage()方法本身就允许返回null：如果异常是通过无参构造或者传入null消息的构造函数创建的，getMessage()就会返回null。

除非第三方库的官方文档明确标注了SomeCustomException的getMessage()永远不会为null，否则你绝对不能省略这些空检查——一旦第三方库更新或者某个边缘场景触发了null消息，你的代码就会直接因NPE崩溃。

3. 如何重构这个多条件if，让它更高效优雅？ #

这里有几个实用的优化方案：

• 封装成工具方法：把空检查和包含判断的逻辑抽成复用的静态方法，业务代码会更简洁干净：

  private static boolean doesExceptionContainMessage(Throwable e, String target) {
      return e != null && e.getMessage() != null && e.getMessage().contains(target);
  }
  // 调用时：
  if (doesExceptionContainMessage(e, "BOOM")) {
      // 你的处理逻辑
  }
  

• 用Java 8+的Optional简化：用Optional的链式调用替代嵌套条件，可读性更好：

  if (Optional.ofNullable(e)
              .map(Throwable::getMessage)
              .filter(msg -> msg.contains("BOOM"))
              .isPresent()) {
      // 你的处理逻辑
  }
  

• 借助现成工具类（如果项目已引入）：如果你的项目用了Apache Commons Lang或者Guava，它们的工具类已经帮你处理了null情况。比如Commons Lang的StringUtils.contains()：

  // StringUtils.contains会自动处理第一个参数为null的情况，直接返回false
  if (e != null && StringUtils.contains(e.getMessage(), "BOOM")) {
      // 你的处理逻辑
  }
  

额外建议 #

其实依赖异常消息来判断异常场景是不太推荐的——因为第三方库可能会在后续版本里修改消息文案（比如做国际化、优化提示语），到时候你的判断逻辑就直接失效了。如果可以的话，建议看看第三方库有没有提供更可靠的判断方式：比如有没有自定义的错误码字段（e.getErrorCode()）、或者针对不同错误场景抛出不同的异常子类，这些都比判断消息要稳定得多。

备注：内容来源于stack exchange，提问作者PatPanda