Il lancio di nuove RuntimeExceptions in un codice non raggiungibile è un cattivo stile?

Mi è stato assegnato il compito di mantenere un'applicazione scritta qualche tempo fa da sviluppatori più qualificati. Mi sono imbattuto in questo pezzo di codice:

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

Sono curioso di sapere se il lancio RuntimeException("cannot reach here")è giustificato. Probabilmente mi manca qualcosa di ovvio sapendo che questo pezzo di codice proviene da un collega più esperto.
EDIT: Ecco il corpo di ripensamento a cui si riferivano alcune risposte. Ho ritenuto non importante in questa domanda.

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

Innanzitutto, grazie per aver ascoltato la tua domanda e averci mostrato cosa rethrowfa. Quindi, in effetti, ciò che fa è convertire le eccezioni con proprietà in classi di eccezioni più dettagliate. Più su questo più tardi.

Dal momento che non ho veramente risposto alla domanda principale in origine, eccolo qui: sì, è generalmente un cattivo stile generare eccezioni di runtime in codice non raggiungibile; faresti meglio a usare le asserzioni o, meglio ancora, a evitare il problema. Come già sottolineato, il compilatore qui non può essere sicuro che il codice non esca mai dal try/catchblocco. Puoi riformattare il tuo codice sfruttando il fatto che ...

Gli errori sono valori

^{(Non sorprende, è ben noto in go )}

Facciamo un esempio più semplice, quello che ho usato prima della tua modifica: immagina di registrare qualcosa e creare un'eccezione wrapper come nella risposta di Konrad . Chiamiamolo logAndWrap.

Invece di lanciare l'eccezione come effetto collaterale di logAndWrap, potresti lasciarlo fare il suo lavoro come effetto collaterale e fargli restituire un'eccezione (almeno, quella data in input). Non è necessario utilizzare generici, solo funzioni di base:

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

Quindi, throwesplicitamente, e il tuo compilatore è felice:

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

E se ti dimentichi di throw?

Come spiegato nel commento di Joe23 , un modo di programmazione difensiva per garantire che l'eccezione sia sempre generata consisterebbe nel fare esplicitamente un throw new CustomWrapperException(exception)alla fine di logAndWrap, come è fatto da Guava . In questo modo, sai che verrà generata l'eccezione e il tuo analizzatore di tipi è felice. Tuttavia, le eccezioni personalizzate devono essere eccezioni non selezionate, il che non è sempre possibile. Inoltre, valuterei il rischio che uno sviluppatore manchi di scrivere throwper essere molto basso: lo sviluppatore deve dimenticarlo e il metodo circostante non dovrebbe restituire nulla, altrimenti il ​​compilatore rileverà un ritorno mancante. Questo è un modo interessante per combattere il sistema dei tipi e funziona, però.

rigenerare

L'attuale rethrowpuò anche essere scritto come una funzione, ma ho problemi con la sua attuale implementazione:

• Ci sono molti cast inutili come I cast sono infatti richiesti (vedi commenti):

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

• Quando si generano / restituiscono nuove eccezioni, quella vecchia viene scartata; nel seguente codice, a MailLoginNotAvailableExceptionnon mi consente di sapere quale accesso non è disponibile, il che è scomodo; inoltre, stacktraces sarà incompleto:

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

• Perché il codice di origine non genera in primo luogo quelle eccezioni specializzate? Ho il sospetto che rethrowvenga utilizzato come livello di compatibilità tra un sottosistema (mailing) e la logica di business (forse l'intento è quello di nascondere i dettagli di implementazione come eccezioni generate sostituendole con eccezioni personalizzate). Anche se concordo sul fatto che sarebbe meglio avere un codice privo di catture, come suggerito nella risposta di Pete Becker , non credo che avrai l'opportunità di rimuovere il codice catche rethrowqui senza importanti refactoring.

Questa rethrow(e);funzione viola il principio secondo il quale in circostanze normali una funzione restituirà, mentre in circostanze eccezionali una funzione genererà un'eccezione. Questa funzione viola questo principio generando un'eccezione in circostanze normali. Questa è la fonte di tutta la confusione.

Il compilatore presuppone che questa funzione tornerà in circostanze normali, quindi, per quanto può dire il compilatore, l'esecuzione può raggiungere la fine della retrieveUserMailConfigurationfunzione, a quel punto è un errore non avere returnun'istruzione. Il RuntimeExceptionlancio lì dovrebbe alleviare questa preoccupazione del compilatore, ma è un modo piuttosto goffo di farlo. Un altro modo per prevenire l' function must return a valueerrore è aggiungere una return null; //to keep the compiler happydichiarazione, ma secondo me è ugualmente goffo.

Quindi, personalmente, vorrei sostituire questo:

rethrow(e);

con questo:

report(e); 
throw e;

o, meglio ancora, (come suggerito coredump ), con questo:

throw reportAndTransform(e);

Pertanto, il flusso di controllo sarebbe reso evidente al compilatore, quindi il tuo finale throw new RuntimeException("cannot reach here");diventerebbe non solo ridondante, ma in realtà nemmeno compilabile, poiché sarebbe contrassegnato dal compilatore come codice irraggiungibile.

Questo è il modo più elegante e in realtà anche il più semplice per uscire da questa brutta situazione.

Il throwfu probabilmente aggiunto per aggirare il "metodo deve restituire un valore" errore che altrimenti si verificherebbe - il flusso di dati di Java analizzatore è abbastanza intelligente per capire che non returnè necessario dopo una throw, ma non dopo la vostra abitudine rethrow()metodo, e non v'è alcuna @NoReturnannotazione che potresti usare per risolvere questo problema.

Tuttavia, la creazione di una nuova eccezione nel codice non raggiungibile sembra superflua. Scriverei semplicemente return null, sapendo che in realtà non succede mai.

Il

throw new RuntimeException("cannot reach here");

L'istruzione chiarisce a una PERSON che legge il codice cosa sta succedendo, quindi è molto meglio che restituire null, ad esempio. Inoltre, semplifica il debug se il codice viene modificato in modo imprevisto.

Tuttavia rethrow(e)sembra proprio sbagliato! Quindi nel tuo caso penso che il refactoring del codice sia un'opzione migliore. Vedi le altre risposte (mi piace il meglio di coredump) per i modi in cui ordinare il codice.

Non so se c'è una convenzione.

Ad ogni modo, un altro trucco sarebbe quello di fare così:

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

Tenendo conto di ciò:

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

E non RuntimeExceptionè più necessario alcun artificiale . Anche se in rethrowrealtà non restituisce mai alcun valore, ora è abbastanza buono per il compilatore.

Restituisce un valore in teoria (firma del metodo), quindi è esente dal farlo in quanto genera un'eccezione.

Sì, potrebbe sembrare strano, ma poi di nuovo - lanciare un fantasma RuntimeExceptiono restituire valori nulli che non saranno mai visti in questo mondo - non è nemmeno esattamente una cosa di bellezza.

Cercando la leggibilità, potresti rinominare rethrowe avere qualcosa di simile:

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

Se si rimuove trycompletamente il blocco, non è necessario il rethrowo il throw. Questo codice fa esattamente la stessa cosa dell'originale:

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

Non lasciarti ingannare dal fatto che provenga da sviluppatori più esperti. Questo è il marciume del codice e succede sempre. Basta aggiustarlo.

EDIT: ho letto male rethrow(e)come semplicemente rilanciando l'eccezione e. Se quel rethrowmetodo fa effettivamente qualcosa di diverso dal ri-lanciare l'eccezione, allora liberarsene cambia la semantica di questo metodo.