到達不能なコードで新しいRuntimeExceptionをスローするのは悪いスタイルですか？

少し前に、より熟練した開発者によって書かれたアプリケーションを保守することになりました。私はこのコードに出会いました：

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ブロック。あなたはそれを活用することでコードをリファクタリングすることができます...

エラーは値です

^{（当然、goでよく知られています）}

編集する前に使用した、より単純な例を使用してみましょう。何かを記録し、Konradの答えのようにラッパー例外を作成していると想像してください。。それを呼び出しましょう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のコメントで説明されているように、例外が常にスローされるようにするための防御的なプログラミング方法は、Guava.Throwablesによって行われるようにthrow new CustomWrapperException(exception)、最後に明示的に行うlogAndWrapことです。そうすれば、例外がスローされることがわかり、タイプアナライザーが満足します。ただし、カスタム例外は未チェックの例外にする必要がありますが、これは常に可能とは限りません。また、開発者が書くことができないリスクを評価します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（郵送）サブシステムとbusineessロジック（多分意図は、カスタム例外によってそれらを交換することによってスローされた例外のような非表示の実装の詳細にある）間の互換性層として使用されています。私はあることに同意した場合でもキャッチフリーのコードを持っているピート・ベッカーの答えで提案されているように、それは、良いだろう、私はあなたが削除する機会があるでしょうとは思わない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;

または、より良い、（コアダンプが示唆したように）、これで：

throw reportAndTransform(e);

したがって、制御の流れがコンパイラーに明らかになるため、コンパイラーthrow new RuntimeException("cannot reach here");が到達不能コードとしてフラグを立てるため、ファイナルは冗長になるだけでなく、実際にはコンパイルできなくなります。

これは、このelegantい状況から抜け出す最もエレガントで実際に最も簡単な方法です。

throw何がいることを理解していないためにスマート十分であるJavaのデータフロー解析-おそらく、そうでない場合に発生する「メソッドが値を返さなければなりません」というエラーが周りを取得するために追加されたreturn後に必要でthrowはなく、カスタム後rethrow()方法、および何もありません@NoReturn注釈これを修正するために使用できます。

それにもかかわらず、到達不能なコードで新しい例外を作成することは不要なようです。return nullそれが実際に決して起こらないことを知って、私は単に書くでしょう。

の

throw new RuntimeException("cannot reach here");

声明は、それがクリアになりPERSON、何が起こっているコードを読んでそう多くは、その後、例えばヌルを返す方が良いです。また、コードが予期しない方法で変更された場合のデバッグが容易になります。

しかし、rethrow(e)間違っているようです！だから、中にあなたの場合、私は、コードをリファクタリングすることは良いオプションだと思います。コードを整理する方法については、他の回答（コアダンプのベストが好きです）を参照してください。

コンベンションがあるかどうかはわかりません。

とにかく、別のトリックはそうすることです：

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この世界では決して見られないヌルを返します-それは正確な美しさでもありません。

読みやすくするために、名前を変更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メソッドが実際に例外を再スローする以外の何かを行う場合、それを取り除くことはこのメソッドのセマンティクスを変更します。