在无法到达的代码中抛出新的RuntimeExceptions是否不好？

我被指派去维护一个由更熟练的开发人员编写的应用程序。我遇到了这段代码：

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
        try {
            return translate(mailManagementService.retrieveUserMailConfiguration(id));
        } catch (Exception e) {
            rethrow(e);
        }
        throw new RuntimeException("cannot reach here");
    }

我很好奇投掷RuntimeException("cannot reach here")是否合理。知道这段代码来自经验丰富的同事，我可能会漏掉一些明显的东西。
编辑：这是一些答案所指的扔尸体。我认为这个问题并不重要。

private void rethrow(Exception e) throws MailException {
        if (e instanceof InvalidDataException) {
            InvalidDataException ex = (InvalidDataException) e;
            rethrow(ex);
        }
        if (e instanceof EntityAlreadyExistsException) {
            EntityAlreadyExistsException ex = (EntityAlreadyExistsException) e;
            rethrow(ex);
        }
        if (e instanceof EntityNotFoundException) {
            EntityNotFoundException ex = (EntityNotFoundException) e;
            rethrow(ex);
        }
        if (e instanceof NoPermissionException) {
            NoPermissionException ex = (NoPermissionException) e;
            rethrow(ex);
        }
        if (e instanceof ServiceUnavailableException) {
            ServiceUnavailableException ex = (ServiceUnavailableException) e;
            rethrow(ex);
        }
        LOG.error("internal error, original exception", e);
        throw new MailUnexpectedException();
    }


private void rethrow(ServiceUnavailableException e) throws
            MailServiceUnavailableException {
        throw new MailServiceUnavailableException();
    }

private void rethrow(NoPermissionException e) throws PersonNotAuthorizedException {
    throw new PersonNotAuthorizedException();
}

private void rethrow(InvalidDataException e) throws
        MailInvalidIdException, MailLoginNotAvailableException,
        MailInvalidLoginException, MailInvalidPasswordException,
        MailInvalidEmailException {
    switch (e.getDetail()) {
        case ID_INVALID:
            throw new MailInvalidIdException();
        case LOGIN_INVALID:
            throw new MailInvalidLoginException();
        case LOGIN_NOT_ALLOWED:
            throw new MailLoginNotAvailableException();
        case PASSWORD_INVALID:
            throw new MailInvalidPasswordException();
        case EMAIL_INVALID:
            throw new MailInvalidEmailException();
    }
}

private void rethrow(EntityAlreadyExistsException e)
        throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
    switch (e.getDetail()) {
        case LOGIN_ALREADY_TAKEN:
            throw new MailLoginNotAvailableException();
        case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
            throw new MailEmailAddressAlreadyForwardedToException();
    }
}

private void rethrow(EntityNotFoundException e) throws
        MailAccountNotCreatedException,
        MailAliasNotCreatedException {
    switch (e.getDetail()) {
        case ACCOUNT_NOT_FOUND:
            throw new MailAccountNotCreatedException();
        case ALIAS_NOT_FOUND:
            throw new MailAliasNotCreatedException();
    }
}

首先，感谢您对问题的回答，并向我们展示了rethrow它的作用。因此，实际上，它的作用是将具有属性的异常转换为更细粒度的异常类。稍后再详细介绍。

因为我最初并没有真正回答主要问题，所以可以解决：是的，在无法访问的代码中抛出运行时异常通常是不好的风格；您最好使用断言，甚至更好地避免问题。正如已经指出的，这里的编译器不能确保代码永远不会走出代码try/catch块。您可以利用以下优势来重构代码：

错误就是价值

^{（毫不奇怪，它是众所周知的）}

让我们使用一个更简单的示例，即我在编辑之前使用的示例：想象一下您正在记录某些内容并构建一个包装异常，例如Konrad的answer。叫它logAndWrap。

可以将异常作为副作用进行处理logAndWrap，而不是将异常作为的副作用抛出，并使其返回异常（至少是输入中给出的异常）。您不需要使用泛型，只需使用基本功能即可：

private Exception logAndWrap(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    return new CustomWrapperException(exception);
}

然后，您throw显式地使编译器满意：

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     throw logAndWrap(e);
}

如果您忘记了该throw怎么办？

正如上文Joe23的评论，一个防御性编程的方式来确保异常始终抛出就在于明确地做一个throw new CustomWrapperException(exception)在年底logAndWrap，因为它是由做Guava.Throwables。这样，您就知道将引发异常，并且类型分析器很高兴。但是，您的自定义异常需要是未检查的异常，这并不总是可能的。另外，我将开发人员丢失编写的风险评估为throw非常低：开发人员必须忘记它，并且周围的方法不应返回任何内容，否则编译器将检测到丢失的返回。这是对抗类型系统的一种有趣方式，但是它确实有效。

重新投掷

实际rethrow也可以编写为一个函数，但是我目前的实现存在问题：

• 有很多无用的演员，例如 实际上需要强制转换（请参阅评论）：

  if (e instanceof ServiceUnavailableException) {
      ServiceUnavailableException ex = (ServiceUnavailableException) e;
      rethrow(ex);
  }

• 当抛出/返回新的异常时，旧的异常被丢弃；在以下代码中，a MailLoginNotAvailableException不允许我知道哪个登录不可用，这很不方便；此外，堆栈跟踪将不完整：

  private void rethrow(EntityAlreadyExistsException e)
      throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
      switch (e.getDetail()) {
          case LOGIN_ALREADY_TAKEN:
              throw new MailLoginNotAvailableException();
          case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
              throw new MailEmailAddressAlreadyForwardedToException();
      }
  }

• 为什么原始代码不首先抛出那些专门的异常？我怀疑这rethrow被用作（邮件）子系统和业务逻辑之间的兼容层（也许目的是通过用自定义异常替换它们来隐藏诸如抛出的异常之类的实现细节）。即使我同意像Pete Becker的回答中所建议的那样具有更好的捕获性代码会更好，但我认为如果不进行重大重构，您将没有机会在此处删除catch和rethrow代码。

此rethrow(e);函数违反了以下原则：在正常情况下，一个函数将返回，而在特殊情况下，一个函数将引发异常。此功能在正常情况下会引发异常，从而违反了该原理。这就是所有困惑的根源。

编译器假定此函数将在正常情况下返回，因此，就编译器所知，执行可能会到达retrieveUserMailConfiguration函数的末尾，此时，没有return语句是错误的。该RuntimeException抛出那里应该减轻编译器的这个问题，但它是这样做的一个非常笨拙的方法。防止function must return a value错误的另一种方法是添加一条return null; //to keep the compiler happy语句，但是在我看来，这同样笨拙。

因此，就我个人而言，我将替换为：

rethrow(e);

有了这个：

report(e); 
throw e;

或者更好的是（如coredump建议的那样）：

throw reportAndTransform(e);

因此，控制流对于编译器throw new RuntimeException("cannot reach here");将变得显而易见，因此最终编译器不仅变得多余，而且实际上甚至不可编译，因为编译器会将其标记为不可访问的代码。

这是摆脱这种丑陋状况的最优雅，实际上也是最简单的方法。

将throw可能已添加，以绕过“方法必须返回一个值”可能发生的错误-在Java数据流分析仪是足够聪明，明白，没有return必要经过throw，但没有你的自定义后rethrow()的方法，并没有@NoReturn标注您可以用来解决此问题。

但是，在无法访问的代码中创建新的Exception似乎是多余的。我会简单地写return null，知道它确实不会发生。

的

throw new RuntimeException("cannot reach here");

陈述清楚地表明 PERSON读书是怎么回事的代码，所以是好多了，然后例如返回null。如果以意外方式更改了代码，这也使调试变得更容易。

但是rethrow(e)只是看起来错了！因此，就您而言，我认为重构代码是一个更好的选择。有关整理代码的方法，请参见其他答案（我最喜欢coredump）。

我不知道有没有约定。

无论如何，另一个技巧就是这样做：

private <T> T rethrow(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    throw new CustomWrapperException(exception);
}

考虑到这一点：

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     return rethrow(e);
}

RuntimeException不再需要人工操作。即使rethrow从不实际返回任何值，对于现在的编译器来说已经足够了。

它确实会返回一个理论上的值（方法签名），然后实际上将其免除，因为它引发了异常。

是的，看起来可能很奇怪，但是再说一次-抛出一个幻影RuntimeException，或者返回在这个世界上永远不会出现的null-也不完全是美。

为了提高可读性，您可以重命名rethrow并添加以下内容：

} catch (Exception e) {
     return nothingJustRethrow(e);
}

如果您try完全删除了该块，则不需要rethrow或throw。此代码与原始代码完全相同：

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
    return translate(mailManagementService.retrieveUserMailConfiguration(id));
}

不要让它来自经验丰富的开发人员的事实欺骗您。这是代码腐烂，并且一直在发生。修复它。

编辑：我误读rethrow(e)为只是重新引发异常e。如果该rethrow方法实际上除了重新引发异常之外还执行其他操作，则将其删除确实会更改此方法的语义。