タグ付けされた質問 「checked-exceptions」

「Effective Java」のジョシュア・ブロックは、 回復可能な状態にはチェック済み例外を使用し、プログラミングエラーには実行時例外を使用します（第2版のアイテム58） 私がこれを正しく理解しているか見てみましょう。 チェック済み例外についての私の理解は次のとおりです。 try{ String userInput = //read in user input Long id = Long.parseLong(userInput); }catch(NumberFormatException e){ id = 0; //recover the situation by setting the id to 0 } 1.上記はチェック済み例外と見なされますか？ 2. RuntimeExceptionは未チェックの例外ですか？ 未チェックの例外についての私の理解は次のとおりです。 try{ File file = new File("my/file/path"); FileInputStream fis = new FileInputStream(file); }catch(FileNotFoundException e){ //3. …

703 java  exception  runtimeexception  checked-exceptions  unchecked-exception 

何年もの間、私は次の質問に対して適切な答えを得ることができませんでした：一部の開発者はなぜチェックされた例外に反対するのですか？私は数多くの会話をしたり、ブログで物事を読んだり、ブルース・エッケルが言わなければならなかったことを読んだりしました（私が最初に見た人が彼らに反対して声を上げました）。 私は現在、いくつかの新しいコードを書いており、例外の処理方法に細心の注意を払っています。「チェックされた例外は好きではない」群衆の視点を確認しようとしていますが、それでも確認できません。 私が行ったすべての会話は、同じ質問に答えられずに終わります...設定させてください： 一般的に（Javaの設計方法から）、 Error 決して捕まってはならないもののためのものです（VMにはピーナッツアレルギーがあり、誰かがピーナッツの瓶を落としました） RuntimeException プログラマーが間違ったことに使用されます（プログラマーが配列の最後を離れてウォークしました） Exception（を除くRuntimeException）は、プログラマーの制御が及ばないもののためのものです（ファイルシステムへの書き込み中にディスクがいっぱいになり、プロセスのファイルハンドルの制限に達したため、これ以上ファイルを開くことができません） Throwable 単にすべての例外タイプの親です。 私がよく耳にする議論は、例外が発生した場合、開発者はすべてプログラムを終了することです。 私がよく耳にするもう1つの主張は、チェックされた例外はコードのリファクタリングを難しくするというものです。 「私がやろうとしていることはすべて終了する」という議論の場合、終了する場合でも、適切なエラーメッセージを表示する必要があるということです。エラーの処理に注意を払っているだけの場合、プログラムが終了したときにユーザーは、理由を明確に示さずに過度に満足することはありません。 「リファクタリングが難しくなる」群衆にとって、それは適切な抽象化レベルが選択されなかったことを示しています。宣言はメソッドが投げるのではなくIOException、IOExceptionより多くの何が起こっているに適している例外に変換する必要があります。 Mainのラップに問題はありませんcatch(Exception)（または、場合によってcatch(Throwable)は、プログラムが正常に終了できるようにするために-しかし、常に必要な特定の例外をキャッチします。これにより、少なくとも適切な表示を行うことができますエラーメッセージ。 人々が決して答えない質問はこれです： RuntimeException サブクラスではなくサブクラスをスローする場合、Exception 何をキャッチすることになっているのかをどのようにして知るのですか？ 答えがcatchの場合は、Exceptionシステム例外と同じ方法でプログラマエラーも処理しています。それは私には間違っているようです。 キャッチThrowableすると、システム例外とVMエラー（など）を同じように処理していることになります。それは私には間違っているようです。 答えが、スローされていることがわかっている例外だけをキャッチすることである場合、どのような例外がスローされているかをどのようにして知るのですか？プログラマXが新しい例外をスローし、それをキャッチするのを忘れた場合はどうなりますか？それは私にとって非常に危険なようです。 スタックトレースを表示するプログラムは間違っていると思います。チェックされた例外を好まない人はそのように感じませんか？ それで、チェックされた例外が気に入らない場合は、なぜそうしないのかを説明し、答えられない質問に答えてください。 編集：私はどちらのモデルをいつ使用するかについてのアドバイスを探していません、私が探しているのは、人々がそこRuntimeExceptionから拡張するのが好きではないために拡張する理由、Exceptionおよび/または例外をキャッチしてからスローをRuntimeException追加するのではなく、再スローする理由です彼らの方法。チェック例外を嫌う動機を理解したい。

456 java  exception  checked-exceptions 

Java 8ストリーム/ラムダからCHECKED例外をスローするにはどうすればよいですか？ つまり、次のようなコードをコンパイルしたいのです。 public List<Class> getClasses() throws ClassNotFoundException { List<Class> classes = Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String") .map(className -> Class.forName(className)) .collect(Collectors.toList()); return classes; } Class.forName()上記のメソッドClassNotFoundExceptionはチェックされているをスローするため、このコードはコンパイルされません。 チェック済みの例外をランタイム例外内にラップせず、代わりにラップされた未チェックの例外をスローしたくないことに注意してください。チェックされた例外自体をスローし、醜いtry/ catchesをストリームに追加しないでください。

287 java  lambda  java-8  java-stream  checked-exceptions 

Java（または例外がチェックされている他の言語）では、独自の例外クラスを作成するときに、クラスをチェックするかチェックしないかをどのように決定しますか？ 私の本能は、チェックされた例外は呼び出し側が何らかの生産的な方法で回復できる可能性がある場合に呼び出され、チェックされていない例外は回復不可能な場合により多くなるが、私は他の人の考えに興味があると言うことです。

213 java  exception  checked-exceptions 

class throwseg1 { void show() throws Exception { throw new Exception("my.own.Exception"); } void show2() throws Exception // Why throws is necessary here ? { show(); } void show3() throws Exception // Why throws is necessary here ? { show2(); } public static void main(String s[]) throws Exception // Why throws …

97 java  exception-handling  unhandled-exception  throws  checked-exceptions