[解決済み] Javaでは、どのような場合にチェック例外を作成し、どのような場合に実行時例外を作成すればよいのでしょうか。重複

質問

重複の可能性があります。

チェックされた例外とチェックされていない例外を選択する場合

どのような場合にチェックありの例外を作り、どのような場合に実行時例外を作るべきでしょうか。

例えば、以下のようなクラスを作ったとします。

public class Account {
    private float balance;

    /* ... constructor, getter, and other fields and methods */

    public void transferTo(Account other, float amount) {
        if (amount > balance)
            throw new NotEnoughBalanceException();
        /* ... */
    }
}

どのように NotEnoughBalanceException ? それは Exception それとも RuntimeException ? それとも IllegalArgumentException を使うべきでしょうか？

どのように解決するのですか？

このトピックについては、多くの意見があります。 私の前職では、ランタイム例外が実稼働環境 (agedwards.com) に現れるまで忘れ去られるという現実的な問題に遭遇しましたので、チェック済みの例外のみを使用するように解決しました。

現在の仕事では、多くの場合、またはすべての場合においてランタイム例外に賛成する人が多いことに気づきました。

CheckedExceptionsを使用すると、私はコンパイル時に呼び出し側で少なくとも例外を認識することを余儀なくされます。 ランタイム例外を使用すると、私はコンパイラーによって強制されませんが、私にそれを処理させるユニット テストを書くことができます。 私は、バグが早期に発見されればされるほど、それを修正するのがより安くなると今でも信じているので、この理由でCheckedExceptionsを好みます。

哲学的な観点から言うと、メソッド呼び出しは呼び出し側と被呼び出し側の間である程度契約していることになります。 コンパイラーは渡されるパラメーターの型を強制するので、出口で型を強制させるのは対称的であると思われます。 すなわち、戻り値または例外です。

私の経験では、チェックされた例外を使用しているとき、より高い品質、つまり、正しく動作するコードを得ることができます。 チェックされた例外はコードを乱雑にするかもしれませんが、これに対処するためのテクニックがあります。 私は、レイヤーの境界を渡すときに例外を翻訳するのが好きです。 なぜなら、次のレイヤーは、私がSQLデータベースに永続化していることは気にしないはずですが、何かが永続化できなかったかどうかを知りたがるからです。 私が使っているもう一つのテクニックは、例外の単純な階層を作ることです。 これにより、スーパークラスをキャッチし、本当に重要なときだけ個々のサブクラスを処理することができるので、1つ上の層でよりクリーンなコードを書くことができます。