なぜJavaの人々は頻繁に例外を黙って消費するのですか？

これまで本格的なJavaコーディングを行ったことはありませんでしたが、既存のスキル（DelphiとC＃）に基づいて構文、ライブラリ、概念を学びました。私がほとんど理解していないことの1つは、次のprintStackTraceようにした後、例外を黙って消費するコードをたくさん見たことです。

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
        }
    }

私が遭遇したほとんどすべてのJavaの記事とプロジェクトには、このようなコードがあります。私の知識に基づくと、これは非常に悪いことです。ほとんどの場合、例外は次のように外部コンテキストに転送されます。

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
            throw new AssertionError(e);
        }
    }

ほとんどの場合、例外は、基盤となるフレームワーク（Java Swingなど）に属する最も外側のループで処理されるはずです。Javaの世界でこのようにコーディングするのが標準のように見えるのはなぜですか？困惑しています。

私の経歴に基づいて、printStackTraceを完全に削除したいと思います。私は単に未処理の別名RuntimeException（または、さらに良いAssertionError）として再スローし、それを最も適切な場所であるフレームワークの最も外側のループでキャッチしてログに記録します。

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            throw new AssertionError(e);
        }
    }

私はいつも考えていました、それは次のシナリオに似ています：

「男が撃たれる。

彼は息を止め、バスに乗るのに十分な力を持っています。

10マイル後、男はバスを降り、数ブロック歩いて死んだ。」

警察が体に着いたとき、彼らは今起こったことの手がかりを持っていません。彼らは最終的に持っているかもしれませんが、それははるかに困難です。

より良いのは：

「男は撃たれ、彼は即座に死にます、そして、体は殺人がちょうど起こったところに正確にあります。」

警察が到着すると、すべての証拠が整っています。

システムに障害が発生した場合は、迅速に障害を発生させることをお勧めします

質問への対処：

1. 無知。
   +
2. 怠惰

編集：

もちろん、キャッチセクションは便利です。

例外を除いて何かを行うことができる場合は、それを行う必要があります。

おそらくそれは与えられたコードの例外ではなく、おそらくそれは予想されるものです（そして私のアナロジーでは防弾ジャケットのようなもので、男はそもそもショットを待っていました）。

そして、はい、キャッチは抽象化に適切な例外をスローするために使用できます

通常、これは、IDEが、問題のあるコードをその例外処理でtry-catchブロックにラップする便利な「クイックフィックス」を提供しているためです。アイデアはあなたが実際に何かをするということですが、怠惰な開発者はしません。

これは間違いなく悪い形です。

これは古典的なストローマンの議論です。 printStackTrace()デバッグ支援です。あなたがブログや雑誌でそれを見た場合はライターがポイントを示すに興味があったので、それはだった他の例外処理よりを。本番コードでそれを見た場合、そのコードの開発者は無知または怠惰であり、それ以上のものではありませんでした。これは、「Javaの世界」での一般的な慣行の例として取り上げるべきではありません。

1. Javaでは、すべての例外を明示的に処理する必要があります。あなたのコードの呼び出しが宣言されていること方法がFooExceptionとBarExceptionあなたのコードをスローする場合はMUSTのこれらの例外をハンドル（またはスロー）。これに対する唯一の例外は、忍者のように沈黙しているRuntimeExceptionです。
2. 多くのプログラマーは怠け者であり（私自身も含まれます）、スタックトレースを印刷するのは非常に簡単です。

これが行われる理由は2つあることがよくあります

1. プログラマーは怠け者でした
2. プログラマーは、そこのコンポーネントへのエントリポイントを（正しくまたは誤って）保護したかった

これはJavaに限った現象ではないと思います。このようなコーディングは、C＃やVB.Netでもよく見られます。

表面的にはかなり衝撃的でひどいように見えます。しかし、実際にはそれは新しいことではありません。これは、エラーコードの戻り値と例外を使用するC ++アプリケーションで常に発生します。ただし、致命的な可能性のある戻り値を無視しても、voidを返す関数を呼び出すのと実際には何の違いも見られないという違いがあります。

Foo* pFoo = ...;
pFoo->SomeMethod(); // Void or swallowing errors, who knows?

このコードは見た目は良くなりますが、SomeMethod（）がHResultを返すと言った場合、意味的には例外を飲み込むのと同じです。

チェックされた例外のため失敗した実験があります

（多分printStackTrace（）が本当の問題ですか？:)

この種の緩いエラー処理動作がJavaプログラマーにとって基本的なものであることを暗示する口調に少し憤慨していると言わざるを得ません。確かに、Javaプログラマーは、他のすべてのプログラマーと同じように怠惰になる可能性があり、Javaは人気のある言語であるため、例外を飲み込むコードがたくさんあることでしょう。

また、他の場所で指摘されているように、個人的には問題はありませんが、Javaが強制的にチェック例外を宣言することには理解できるフラストレーションがあります。

私が問題にしているのは、コンテキストを気にせずにWeb上の多数の記事やコードスニペットをざっと読んでいることだと思います。真実は、特定のAPIがどのように機能するか、または何かを開始する方法を説明しようとする技術記事を書いているとき、コードのいくつかの側面をスキップする可能性が非常に高いです-直接ではないエラー処理特に、シナリオ例で例外が発生する可能性が低い場合は、デモンストレーションしている内容に関連するものが廃棄の候補になる可能性があります。

その性質の記事を書く人々は、合理的な信号対雑音比を維持する必要があり、かなり公平に、それはあなたが開発している言語についていくつかの基本を知っていると仮定しなければならないことを意味すると思います。エラーに適切に対処する方法、および他の多くのもの。記事に出くわし、適切なエラーチェックが不足していることに気付いた場合は、それで問題ありません。これらのアイデアを本番コードに組み込むとき（もちろん、正確なコード自体は決してありませんよね？）、作者が賢明に省略したすべてのビットとボブを、最も適切な方法で処理することを確認してください。あなたが開発しているものに適しています。

私は、そのような問題に戻ることなく簡単に説明する非常に高レベルの紹介記事に問題がありますが、エラー処理に関するJavaプログラマーの特定の「考え方」がないことに注意してください。私はあなたの愛するC＃プログラマーの多くが彼らのすべての問題に対処することを気にしないことも知っています。

System.out printまたはe.printStackTrace（）-これは通常、System.outの使用が危険信号であり、誰かがわざわざ勤勉な仕事をしなかったことを意味します。デスクトップJavaアプリケーションを除いて、ほとんどのJavaアプリはロギングを使用する方が良いでしょう。

メソッドの失敗モードが操作なしの場合、理由（および存在）を記録するかどうかに関係なく、例外を食べることはまったく問題ありません。ただし、より一般的には、catch句はある種の例外的なアクションを実行する必要があります。

例外の再スローは、catchを使用して、必要な情報がまだ利用可能なレベルで作業の一部をクリーンアップする場合、または例外を呼び出し元により適した例外タイプに変換する必要がある場合に最適です。

キャッチブロックが実際に空の場合にのみ、サイレントに消費されます。

記事に関する限り、例外の処理方法以外に、他のポイントを証明することの方がおそらく興味深いでしょう。彼らはただ要点をまっすぐに理解し、可能な限り短いコードを持ちたいだけです。

明らかにあなたは正しいですが、例外が「無視」される場合は、少なくともログに記録する必要があります。

他の人が指摘しているように、これが表示される理由は次の3つの理由のいずれかです。

1. IDEがtry-catchブロックを生成しました
   • コードをコピーして貼り付けました
   • 開発者はスタックトレースをデバッグに入れましたが、例外を適切に処理するために戻ってきませんでした

最後のポイントは、発生する可能性が最も低いです。誰も実際にこの方法でデバッグするとは思わないので、私はこれを言います。デバッガーを使用してコードをステップ実行すると、デバッグがはるかに簡単になります。

キャッチブロックで何をすべきかについての最良の説明は、JoshuaBlochによるEffectiveJavaの第9章にあります。

C＃では、すべての例外はランタイム例外ですが、Javaでは、ランタイム例外とチェック済み例外があり、それらをキャッチするか、メソッドで宣言する必要があります。最後に「スロー」があるメソッドを呼び出す場合は、そこに記載されている例外をキャッチするか、メソッドでそれらの例外を宣言する必要があります。

例外処理は記事の主題とは無関係であるため、Java Articlesは通常、スタックトレースを出力するか、コメントを付けます。ただし、プロジェクトでは、例外のタイプに応じて、それについて何かを行う必要があります。

プログラマーが自分の仕事を正しく行えば、これは非常に頻繁に見られるはずです。例外を無視することは悪い、悪い習慣です！しかし、一部の人がこれを行う理由と、より適切な解決策がいくつかあります。

• 「これは起こらない！」確かに、この例外が発生しないことを「知っている」場合もありますが、発生した例外を単に無視するのではなく、「原因」として実行時例外を再スローする方が適切です。私はそれが将来いつか起こるだろうに違いない。;-)

• コードのプロトタイピングそれがうまくいくかどうかを確認するために入力するだけの場合は、発生する可能性のあるすべての例外を無視することをお勧めします。これは私がいくつかの怠惰なキャッチ（Throwable）を行う唯一のケースです。しかし、コードが何か便利なものになる場合は、適切な例外処理を含めます。

• 「どうしたらいいのかわからない！」アプリケーションのこのレイヤーでは適切な処理を実行できないため、発生する例外を飲み込むコード、特にライブラリコードをたくさん見ました。これをしないでください！例外を再スローするだけです（メソッドシグネチャにthrows句を追加するか、例外をライブラリ固有の例外にラップします）。

常に転送するか、実際のコンテキストで適切に処理する必要があります。多くの記事やチュートリアルでは、コードを単純化してより重要なポイントを伝えますが、単純化する最も簡単な方法の1つはエラー処理です（エラー処理に関する記事を書いている場合を除きます:)）。Javaコードは例外処理をチェックするため、単純なサイレント（またはロギングステートメント）catchブロックをオンにするのが、実用的な例を提供する最も簡単な方法です。

サンプルコード以外でこれを見つけた場合は、コードをTDWTFに転送してください。ただし、今ではサンプルが多すぎる可能性があります:)

ほとんどのJavaプログラマーは、例外をどう処理するかを知らないのではないかと心配しています。例外は、「主格」のコーディングを遅くする煩わしさだと常に考えています。もちろん、彼らは完全に間違っていますが、例外を正しく処理することが重要であることを彼らに納得させることは困難です。私がそのようなプログラマーに出会うたびに（それは頻繁に起こります）、私は彼に2つの読書エントリーを与えます：

• 有名なThinkingIn java
• ここで入手可能なBarryRuzekの短くて興味深い記事：www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html

ちなみに、RuntimeExceptionに埋め込まれた例外を再スローするために型指定された例外をキャッチするのは愚かであることに強く同意します。

• あなたがそれを捕まえたら、それを扱ってください。
• それ以外の場合は、メソッドシグネチャを変更して、処理できる/処理できない可能性のある例外を追加します。これにより、呼び出し元が自分でそれを実行できるようになります。

チェックされた例外とインターフェースの組み合わせは、コードが決してスローされない例外を処理しなければならないという状況につながります。（同じことが通常の継承にも当てはまりますが、インターフェイスを使用して説明する方が一般的で簡単です）

理由：インターフェースの実装は、インターフェース仕様で定義されているもの以外の例外をスロー（チェック）しない場合があります。そのため、インターフェイスを実装するクラスのどのメソッドが実際に例外をスローする必要があるかを知らないインターフェイスの作成者は、すべてのメソッドが少なくとも1つのタイプの例外をスローする可能性があると指定する場合があります。例：JDBC。すべてとそのおばあちゃんがSQLExceptionをスローするように宣言されています。

しかし実際には、実際の実装の多くの方法は単純に失敗することはないため、いかなる状況でも例外をスローすることはありません。このメソッドを呼び出すコードは、依然として何らかの方法で例外を「処理」する必要があります。最も簡単な方法は、例外を飲み込むことです。決して実行されることのない、一見役に立たないエラー処理でコードを乱雑にしたいと思う人は誰もいません。

指摘したように、printStackTrace（）の呼び出しは、実際にはサイレント処理ではありません。

この種の例外の「飲み込み」の理由は、チェーンの上位で例外を渡し続ける場合でも、どこかで例外を処理するか、アプリケーションをクラッシュさせる必要があるためです。したがって、情報ダンプで発生するレベルで処理することは、情報ダンプでトップレベルで処理することよりも悪くはありません。

その怠惰な練習-それ以外の何物でもありません。

これは通常、指の動きを増やすのではなく、例外を本当に気にしないときに行われます。

チェックされた例外を再スローする方が良い考えであることに同意しません。キャッチとは取り扱いを意味します。あなたが投げ直す必要があるならば、あなたは捕まえるべきではありません。その場合、メソッドのシグネチャにthrows句を追加します。

チェックされた例外をチェックされていないものにラップすること（たとえば、SpringがチェックされたSQLExceptionをチェックされていない階層のインスタンスにラップする方法）は許容できると言えます。

ロギングは処理と見なすことができます。コンソールに書き込む代わりにlog4jを使用してスタックトレースをログに記録するように例が変更された場合、それは受け入れ可能になりますか？あまり変化はありません、IMO。

本当の問題は、例外的で許容できる回復手順と見なされるものです。例外から回復できない場合は、失敗を報告するのが最善の方法です。

チェックされた例外をチェックされていない例外でラップしないでください。

すべきではないと思われる例外に対処していることに気付いた場合、私のアドバイスは、おそらく間違ったレベルの抽象化で作業しているということです。

詳細を説明します。チェックされた例外とチェックされていない例外は、2つのまったく異なる獣です。チェックされた例外は、エラーコードを返す古い方法に似ています...はい、エラーコードよりも処理がやや面倒ですが、利点もあります。チェックされていない例外は、プログラミングエラーと重大なシステム障害です...言い換えれば、例外的な例外です。例外が何であるかを説明しようとすると、多くの人がこれら2つの非常に異なるケースの違いを認識していないため、完全に混乱します。

彼らはまだこのトリックを学んでいないので：

class ExceptionUtils {
    public static RuntimeException cloak(Throwable t) {
        return ExceptionUtils.<RuntimeException>castAndRethrow(t);
    }

    @SuppressWarnings("unchecked")
    private static <X extends Throwable> X castAndRethrow(Throwable t) throws X {
        throw (X) t;
    }
}

class Main {
    public static void main(String[] args) { // Note no "throws" declaration
        try {
            // Do stuff that can throw IOException
        } catch (IOException ex) {
            // Pretend to throw RuntimeException, but really rethrowing the IOException
            throw ExceptionUtils.cloak(ex);
        }
    }
}

例外の本当のポイントは、エラー処理を簡素化し、エラー検出から分離することです。これは、エラー処理コードがいたるところに散在し、失敗する可能性のあるすべての呼び出しが戻りコードをチェックするエラーコードでエラーを表すのとは対照的です。

例外がエラーを表す場合（ほとんどの場合）、通常、例外を処理する最も合理的な方法は、ベイルアウトして処理を上位層に任せることです。意味のあるセマンティクスが追加されている場合は、別の例外の再スローを検討する必要があります。つまり、このエラーは異常なシステム障害/一時的な（ネットワーク）問題です/これはクライアントまたはサーバー側のエラーなどです。

すべてのエラー処理戦略の中で、最も無知なのは、エラーメッセージを非表示にするか、単に印刷して、何も起こらなかったために先に進むことです。

Sunの人々は、コードをより明示的にしたいと考えており、プログラマーはどの例外がどのメソッドでスローされるかを記述する必要がありました。それは正しい動きのようでした-プロトタイプが与えられた場合、メソッド呼び出しからの見返りとして何を期待するかは誰でも知っています（このタイプの値を返すか、指定されたクラスの1つ（またはそのサブクラス）のインスタンスをスローする可能性があります）。

しかし、多くの無知なJavaプログラマーが判明したため、例外処理を言語のバグ/「機能」であるかのように扱い、回避策が必要であり、最悪またはほぼ最悪の方法でコードを記述します。

• エラーは、それをどう処理するかを決定するのに適していないコンテキストですぐに処理されます。
• サイレントに表示または無視され、それ以上のコードが適切に実行されない場合でも計算が続行されます。
• メソッドの呼び出し元は、正常に終了したかどうかを区別できません。

より「正しい方法」を書く方法は？

• メソッドヘッダーでスローされる可能性のある例外のすべての基本クラスを示します。AFAICREclipseはそれを自動的に行うことができます。
• メソッドプロトタイプのスローリストを意味のあるものにします。長いリストは無意味であり、「例外をスローする」は怠惰です（ただし、例外についてあまり気にしない場合に役立ちます）。
• 「間違った方法」を書くときは、「try {...} catch（Exception e）{e.printStackTrace（）;}」よりも単純な「throwException」の方がはるかに優れており、バイト数も少なくて済みます。
• 必要に応じて、連鎖例外を再スローします。

例外を現在のメソッドの範囲外で処理する場合は、実際にキャッチする必要はありません。代わりに、メソッドのシグネチャに「throws」ステートメントを追加します。

あなたが見たtry / catchステートメントは、プログラマーが例外をその場で処理することを明示的に決定したコードにのみあり、したがってそれ以上スローしません。

開発者も、特定のコンテキストで「正しいことをする」ことの重要性を考慮しようとしていると思います。多くの場合、コードを破棄したり、例外を上向きに伝播しても例外が致命的であるために何も購入されない場合は、「間違ったことをする」ことで時間と労力を節約したほうがよいでしょう。

通常、例外から回復できない場合は例外を飲み込みますが、それは重要ではありません。1つの良い例は、データベース接続を閉じるときにスローされる可能性のあるIOExcetionです。これが発生した場合、本当にクラッシュしますか？そのため、ジャカルタのDBUtilsにはcloseSilentlyメソッドがあります。

ここで、回復できないが重大である（通常はプログラミングエラーが原因である）チェック済み例外については、それらを飲み込まないでください。例外は問題の原因にできるだけ近い場所でログに記録する必要があると思うので、printStackTrace（）呼び出しを削除することはお勧めしません。ビジネスメソッドでこれらの例外を宣言する必要がないという唯一の目的のために、それらをRuntimeExceptionに変換することをお勧めします。createClientAccount（）がProgrammingErrorException（SQLExceptionを読み取る）をスローするなどの高レベルのビジネスメソッドを使用することは実際には意味がありません。SQLにタイプミスがある場合や不正なインデックスにアクセスする場合は何もできません。

経験上、例外を飲み込むことは、ほとんどの場合、印刷されていない場合に有害です。クラッシュした場合に注意を引くのに役立ちます。意図的にそれを行うこともありますが、例外を出力して続行するだけで、問題を見つけて修正できますが、通常、同じコードベースで作業している他のユーザーに悪影響を与えることはありません。 。

私は実際にFail-Fast / Fail-HARDに夢中ですが、少なくともそれを印刷します。例外を実際に「食べる」場合（これは本当に何もしないことです：{}）誰かがそれを見つけるのに数日かかります。

問題は、Javaが、開発者がスローされないことを知っている、またはスローされても気にしない多くのものをキャッチするように強制することです。最も一般的なのはThread.sleep（）です。ここにスレッドの問題を引き起こす可能性のある穴があることはわかっていますが、一般的には、それを中断していないことを知っています。限目。

catchExceptionを使用する理由はたくさんあります。多くの場合、RuntimeExceptionsもキャッチするため、これは悪い考えです。これが発生した後、基になるオブジェクトがどのような状態になるかわかりませんか？これは、予期しない状況では常に困難なことです。コードの残りの部分が後で失敗しないことを信頼できますか。

あなたの例はスタックトレースを出力するので、少なくとも根本的な原因が何であったかがわかります。大規模なソフトウェアプロジェクトでは、これらをログに記録することをお勧めします。そして、ログコンポーネントが例外をスローしないことを期待しましょう。無限ループに陥る可能性もあります（おそらくJVMが強制終了されます）。

チェックされた例外があり、それをメソッドで処理したくない場合は、メソッドに例外をスローさせる必要があります。何か便利なことをする場合にのみ、例外をキャッチして処理します。ユーザーがログを読んで例外を探したり、例外がスローされた場合の対処方法を知ったりする時間がほとんどないため、ログを記録するだけでは、私の本ではあまり役に立ちません。

例外をラップすることはオプションですが、次の場合を除いて、これを行うことはお勧めしません。既存のインターフェイスに一致するように別の例外をスローするか、そのような例外をスローする方法は実際にはありません。

ところで：チェックされた例外を再スローしたい場合は、これを行うことができます

try {
   // do something
} catch (Throwable e) {
   // do something with the exception
   Thread.currentThread().stop(e); // doesn't actually stop the current thread, but throws the exception/error/throwable
}

注：これを行う場合、コンパイラーはこの状況ではこれを行うことができないため、メソッドのthrows宣言が正しいことを確認する必要があります。

それがベストプラクティスだからです。誰もが知っていると思いました。
しかし、冷酷な真実は、例外を除いて作業する方法を本当に理解している人は誰もいないということです。Cエラー処理スタイルは非常に理にかなっています。