Lançar novas RuntimeExceptions em código inacessível é um estilo ruim?

Fui designado para manter um aplicativo escrito há algum tempo por desenvolvedores mais qualificados. Me deparei com este pedaço de código:

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

Estou curioso para saber se jogar RuntimeException("cannot reach here")é justificado. Provavelmente estou perdendo algo óbvio, sabendo que esse código vem de um colega mais experiente.
EDIT: Aqui está o corpo de retrocesso a que algumas respostas se referem. Considero que não é importante nesta questão.

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();
    }
}

Primeiro, obrigado por atualizar sua pergunta e nos mostrar o que rethrowfaz. Então, de fato, o que ele faz é converter exceções com propriedades em classes de exceções mais refinadas. Mais sobre isso mais tarde.

Como eu realmente não respondi a pergunta principal originalmente, aqui vai: sim, geralmente é um estilo ruim lançar exceções de tempo de execução em código inacessível; é melhor usar afirmações ou, melhor ainda, evitar o problema. Como já apontado, o compilador aqui não pode ter certeza de que o código nunca sai do try/catchbloco. Você pode refatorar seu código aproveitando que ...

Erros são valores

^{(Sem surpresa, é bem conhecido em movimento )}

Vamos usar um exemplo mais simples, o que eu usei antes da sua edição: imagine que você esteja registrando algo e criando uma exceção de invólucro, como na resposta do Konrad . Vamos chamá-lo logAndWrap.

Em vez de lançar a exceção como um efeito colateral de logAndWrap, você poderia deixá-lo fazer seu trabalho como efeito colateral e fazê-lo retornar uma exceção (pelo menos, a que foi fornecida na entrada). Você não precisa usar genéricos, apenas funções básicas:

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

Então, você throwexplicitamente, e seu compilador está feliz:

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

E se você esquecer throw?

Como explicado no comentário de Joe23 , uma maneira defensiva de programação para garantir que a exceção seja sempre lançada consistiria em fazer explicitamente um throw new CustomWrapperException(exception)no final de logAndWrap, como é feito pelo Guava.Throwables . Dessa forma, você sabe que a exceção será lançada e seu analisador de tipos ficará feliz. No entanto, suas exceções personalizadas precisam ser desmarcadas, o que nem sempre é possível. Além disso, eu classificaria o risco de um desenvolvedor ausente gravar throwmuito baixo: o desenvolvedor deve esquecê-lo e o método circundante não deve retornar nada, caso contrário, o compilador detectaria um retorno ausente. Esta é uma maneira interessante de combater o sistema de tipos, e funciona, no entanto.

Rethrow

O real também rethrowpode ser escrito como uma função, mas tenho problemas com sua implementação atual:

• Existem muitos elencos inúteis como Elencos são de fato necessários (ver comentários):

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

• Ao lançar / retornar novas exceções, a antiga é descartada; no código a seguir, a MailLoginNotAvailableExceptionnão me permite saber qual login não está disponível, o que é inconveniente; além disso, os traços de pilha serão incompletos:

  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();
      }
  }
  

• Por que o código de origem não lança essas exceções especializadas em primeiro lugar? Eu suspeito que rethrowseja usado como uma camada de compatibilidade entre um subsistema (de correspondência) e a lógica de negócios (talvez a intenção seja ocultar detalhes de implementação, como exceções lançadas, substituindo-as por exceções personalizadas). Mesmo se eu concordar que seria melhor ter um código sem captura, como sugerido na resposta de Pete Becker , não acho que você terá a oportunidade de remover o código catche rethrowaqui sem grandes refatorações.

Essa rethrow(e);função viola o princípio que afirma que, em circunstâncias normais, uma função retornará, enquanto em circunstâncias excepcionais, uma função lançará uma exceção. Essa função viola esse princípio lançando uma exceção em circunstâncias normais. Essa é a fonte de toda a confusão.

O compilador assume que essa função retornará em circunstâncias normais; portanto, até onde o compilador pode dizer, a execução pode chegar ao final da retrieveUserMailConfigurationfunção; nesse momento, é um erro não ter uma returninstrução. A RuntimeExceptionjogada lá deve aliviar essa preocupação do compilador, mas é uma maneira bastante desajeitada de fazê-lo. Outra maneira de evitar o function must return a valueerro é adicionar uma return null; //to keep the compiler happydeclaração, mas isso é igualmente desajeitado na minha opinião.

Então, pessoalmente, eu substituiria isso:

rethrow(e);

com isso:

report(e); 
throw e;

ou, melhor ainda, (como sugerido pelo coredump ), com isso:

throw reportAndTransform(e);

Assim, o fluxo de controle seria tornado óbvio para o compilador, para que sua final throw new RuntimeException("cannot reach here");se tornasse não apenas redundante, mas na verdade nem compilável, pois seria sinalizada pelo compilador como código inacessível.

Essa é a maneira mais elegante e também mais simples de sair dessa situação feia.

O throwprovavelmente foi adicionado para contornar o "método deve retornar um valor" erro que ocorreria de outra maneira - os dados Java fluir analisador é bastante inteligente para compreender que não returné necessário depois de um throw, mas não após o seu costume rethrow()método, e não há nenhuma @NoReturnanotação que você poderia usar para corrigir isso.

No entanto, a criação de uma nova exceção em código inacessível parece supérflua. Eu simplesmente escreveria return null, sabendo que, de fato, nunca acontece.

o

throw new RuntimeException("cannot reach here");

A declaração deixa claro para uma PESSOA que está lendo o código, o que está acontecendo, por isso é muito melhor do que retornar nulo, por exemplo. Também facilita a depuração se o código for alterado de maneira inesperada.

No entanto, rethrow(e)apenas parece errado! Então, no seu caso , acho que refatorar o código é uma opção melhor. Veja as outras respostas (eu gosto mais do coredump) para saber como resolver seu código.

Não sei se existe uma convenção.

De qualquer forma, outro truque seria fazer o seguinte:

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

Permitindo isso:

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

E não RuntimeExceptioné mais necessário artificial . Mesmo que rethrownunca realmente retorne qualquer valor, é bom o suficiente para o compilador agora.

Ele retorna um valor na teoria (assinatura do método) e, em seguida, fica isento de fazê-lo, pois gera uma exceção.

Sim, pode parecer estranho, mas, novamente - jogar um fantasma RuntimeExceptionou retornar nulos que nunca serão vistos neste mundo - também não é exatamente uma coisa de beleza.

Buscando a legibilidade, você pode renomear rethrowe ter algo como:

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

Se você remover o trybloco completamente, não precisará do rethrowou do throw. Este código faz exatamente a mesma coisa que o original:

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

Não deixe que o fato de ser de desenvolvedores mais experientes o engane. Isso é código podre, e acontece o tempo todo. Apenas conserte.

Edição: Eu li errado rethrow(e)como simplesmente re-lançando a exceção e. Se esse rethrowmétodo realmente faz algo diferente de repetir a exceção, livrar-se dela altera a semântica desse método.