Javaでのチェック済み例外とチェックなし例外の理解

「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. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4.さて、上記のコードはチェックされた例外にもなりませんか？このような状況を回復することができますか？できますか？（注：私の3番目の質問はcatch上記の中にあります）

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5.なぜ人々はこれをするのですか？

public void someMethod throws Exception{

}

なぜ彼らは例外が浮上するのですか？エラーをより早く処理しないのですか？なぜ泡立ちますか？

6.正確な例外をバブルアップするか、または例外を使用してマスクする必要がありますか？

以下は私の読みです

Javaでは、いつチェック例外を作成する必要があり、いつランタイム例外にする必要がありますか？

チェックされた例外とチェックされていない例外を選択するタイミング

多くの人は、チェックされた例外（つまり、明示的にキャッチまたは再スローする必要がある例外）はまったく使用すべきではないと述べています。たとえば、C＃で削除されましたが、ほとんどの言語にはありません。したがって、常にRuntimeException（未チェックの例外）のサブクラスをスローできます

ただし、チェック例外は便利だと思います。例外は、APIのユーザーに例外状況の処理方法（回復可能な場合）を考えさせるときに使用します。チェックされた例外がJavaプラットフォームで過剰に使用されているだけで、人々はそれを嫌います。

これが私のトピックの拡張ビューです。

特定の質問に関しては：

1. はNumberFormatExceptionチェック済み例外と見なされますか？
   番号NumberFormatExceptionはチェックされていません（=はのサブクラスですRuntimeException）。どうして？知りません。（しかし、メソッドがあったはずですisValidInteger(..)）

2. でRuntimeExceptionチェックされない例外？
   はい、正確に。

3. ここで何をしますか？
   これは、このコードがどこにあり、何をしたいかによって異なります。UIレイヤー内にある場合-キャッチして警告を表示します。それがサービス層にある場合-それをまったくキャッチしないでください-それをバブルさせてください。ただ例外を飲み込まないでください。ほとんどの場合に例外が発生した場合は、次のいずれかを選択する必要があります。

   • ログに記録して戻る
   • 再スロー（メソッドによってスローされることを宣言）
   • コンストラクタで現在の例外を渡すことにより、新しい例外を構築します

4. さて、上記のコードはチェックされた例外でもありませんか？このような状況を回復することができますか？できますか？
   それはあったかもしれない。しかし、チェックされていない例外をキャッチすることを妨げるものは何もありません

5. なぜ人々Exceptionはスロー句にクラスを追加するのですか？
   ほとんどの場合、人々は何をキャッチし、何を再スローするかを考えるのに怠惰です。投げることExceptionは悪い習慣であり、避けるべきです。

悲しいかな、いつキャッチするか、いつ再スローするか、いつチェック済み例外を使用するか、いつチェックなし例外を使用するかを決定できる単一のルールはありません。これは多くの混乱と多くの悪いコードを引き起こすことに同意します。一般原則はBlochによって述べられています（あなたはその一部を引用しました）。そして、一般的な原則は、それを処理できるレイヤーに例外を再スローすることです。

何かが「チェック済み例外」であるかどうかは、それをキャッチするかどうか、またはcatchブロックで何をするかとは関係ありません。これは例外クラスのプロパティです。サブクラスである何かException を除くためにRuntimeException、そのサブクラスは、チェック例外です。

Javaコンパイラは、チェックされた例外をキャッチするか、メソッドシグネチャでそれらを宣言するように強制します。プログラムの安全性を向上させるはずだったが、大多数の意見は、それが生み出す設計上の問題に値するものではないと思われる。

なぜ彼らは例外が浮上するのですか？エラーを処理しないのは早いほど良いですか？なぜ泡立ちますか？

それが例外のすべてのポイントだからです。この可能性がなければ、例外は必要ありません。それらを使用すると、最初に発生した低レベルのメソッドでエラーを処理するのではなく、選択したレベルでエラーを処理できます。

1. 上記はチェック例外と見なされますか？あなたが例外を処理しているという事実は、それがありませんありませんChecked Exception、それがある場合RuntimeException。

2. ありますか？はいRuntimeExceptionunchecked exception

Checked Exceptionsあるsubclassesのjava.lang.Exception Unchecked Exceptionsですsubclassesのjava.lang.RuntimeException

チェック例外をスローする呼び出しは、try {}ブロックで囲むか、メソッドの呼び出し元の上位レベルで処理する必要があります。その場合、現在のメソッドは、呼び出し側が例外を処理するための適切な準備をできるように、上記の例外をスローすることを宣言する必要があります。

お役に立てれば。

Q：正確な例外をバブルアップするか、例外を使用してマスクする必要がありますか？

A：はい、これは非常に良い質問であり、重要な設計上の考慮事項です。Exceptionクラスは非常に一般的な例外クラスであり、内部の低レベルの例外をラップするために使用できます。カスタム例外を作成して、その中にラップする方がよいでしょう。しかし、そして大きな問題です-根本的な根本原因を曖昧にすることは決してありません。例として、Don't ever次のようにします-

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

代わりに以下を実行してください：

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

元の根本原因を食い尽くすことは、回復を超えた実際の原因を埋め込むことは、アプリケーションログとエラーメッセージへのアクセス権が与えられているすべての運用サポートチームにとって悪夢です。後者の方が優れた設計ですが、開発者が基礎となるメッセージを呼び出し元に渡すことができないため、多くの人はそれを頻繁に使用しません。したがって、しっかりとメモしてくださいAlways pass on the actual exception。アプリケーション固有の例外にラップされているかどうかを確認してください。

キャッチングについて RuntimeExceptions

RuntimeException■原則として、試行錯誤してはなりません。これらは一般にプログラミングエラーを通知するため、そのままにしておく必要があります。代わりに、プログラマは、結果としてになる可能性のあるコードを呼び出す前に、エラー状態を確認する必要がありますRuntimeException。例：

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

これは悪いプログラミング習慣です。代わりに、nullチェックは次のように行われる必要があります-

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

ただし、数値の書式設定など、このようなエラーチェックにコストがかかる場合があります。これを考慮してください-

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

ここで、呼び出し前のエラーチェックは、本質的にparseInt（）メソッド内のすべての文字列から整数への変換コードを複製することを意味するため、努力する価値はありません。開発者が実装すると、エラーが発生しやすくなります。したがって、try-catchを廃止することをお勧めします。

したがってNullPointerException、NumberFormatException両方ともRuntimeExceptions、エラーを起こしやすいコードが導入される可能性を回避するために明示的にNullPointerExceptionキャッチすることをお勧めしNumberFormatExceptionます。

１。例外が不明な場合は、APIを確認してください。

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

２。はい、それを拡張するすべての例外。

３。同じ例外をキャッチしてスローする必要はありません。この場合、新しいファイルダイアログを表示できます。

４。FileNotFoundException は既にチェック済みの例外です。

５。メソッド呼び出しsomeMethodが例外をキャッチすることが期待される場合、後者をスローできます。それは単に「ボールをパスする」だけです。その使用例は、独自のプライベートメソッドでスローし、代わりにパブリックメソッドで例外を処理する場合です。

読みやすいのはOracleのドキュメント自体です。http：//download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

なぜデザイナーは、スコープ内でスローできるすべてのキャッチされていないチェック例外を指定するようにメソッドを強制することを決めたのですか？メソッドによってスローされる可能性のある例外は、メソッドのパブリックプログラミングインターフェイスの一部です。メソッドを呼び出すユーザーは、メソッドがスローする例外について知っておく必要があります。これにより、メソッドに対して何を行うかを決定できます。これらの例外は、そのメソッドのプログラミングインターフェイスの一部であり、そのパラメーターと戻り値と同じです。

次の質問は次のようになります。「メソッドのAPIをドキュメント化すると、スローできる例外も含めて、実行時例外も指定しないのはなぜですか」ランタイム例外は、プログラミングの問題の結果である問題を表します。そのため、APIクライアントコードは、例外から回復したり、何らかの方法で処理したりすることは合理的に期待できません。このような問題には、ゼロによる除算などの算術例外が含まれます。null参照を介してオブジェクトにアクセスしようとするなど、ポインター例外。インデックス付けの例外。たとえば、大きすぎるか小さすぎるインデックスを使用して配列要素にアクセスしようとした場合。

Java言語仕様には、重要な情報も含まれています。

throws句で指定されたチェック済み例外クラスは、メソッドまたはコンストラクタの実装者とユーザーの間の規約の一部です。

一番下の行私見では、ということであることができますいずれかをキャッチしRuntimeException、しかし、あなたがする必要はありませんと、それらが契約の一部ではないとして、実際に実装は、スロー同じ非チェック例外を維持するために必要とされていません。

1）いいえ、NumberFormatExceptionは未チェックの例外です。チェックされていないので、あなたはそれをキャッチしましたが（あなたは必須ではありません）。これは、それがのサブクラスでIllegalArgumentExceptionあるサブクラスだからRuntimeExceptionです。

2）RuntimeExceptionは、すべての未チェックの例外のルートです。のすべてのサブクラスRuntimeExceptionはチェックされていません。その他のすべての例外およびThrowableエラー（はその下にあります）を除いてチェックされますThrowable。

3/4）存在しないファイルを選択したことをユーザーに警告し、新しいファイルを要求することができます。または、無効な何かを入力したことをユーザーに通知するのをやめるだけです。

5）投げて捕まえること'Exception'は悪い習慣です。しかし、より一般的には、他の例外をスローして、呼び出し側がそれを処理する方法を決定できるようにすることができます。たとえば、ファイル入力の読み取りを処理するライブラリを作成し、メソッドに存在しないファイルが渡された場合、その処理方法がわかりません。発信者はもう一度質問するか、終了しますか？したがって、例外をチェーンを呼び出し側に戻します。

多くの場合、unchecked Exceptionプログラマーが入力を検証しなかったために発生NumberFormatExceptionします（最初の質問の場合）。これらの例外を生成しないようにするためのより洗練された方法があるため、それらをキャッチすることはオプションです。

チェック済み-発生する傾向があります。コンパイル時にチェックイン。

例：FileOperations

未チェック-不良データが原因です。実行時にチェックイン。

例えば..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

ここでの例外は不良データが原因であり、コンパイル時にそれを特定することはできません。

チェックされた例外は、コンパイル時にJVMとその関連リソース（files / db / stream / socketなど）によってチェックされます。チェック例外の動機は、コンパイル時にリソースが利用できない場合、アプリケーションはcatch / finallyブロックでこれを処理する代替動作を定義する必要があることです。

チェックされていない例外は、純粋にプログラム上のエラー、誤った計算、nullデータ、またはビジネスロジックの障害でさえ、ランタイム例外につながる可能性があります。コード内のチェックされていない例外を処理/キャッチすることは絶対に問題ありません。

http://coder2design.com/java-interview-questions/からの説明

チェックされていない例外とチェックされた例外の違いについての私のお気に入りの説明は、Javaチュートリアルのトレイル記事「チェックされていない例外-論争」（この投稿ですべての初歩を取得して申し訳ありませんが、ねえ、基本は時々最高です）によって提供されます。

要点のガイドラインは次のとおりです。クライアントが例外からの回復が合理的に期待できる場合は、チェックされた例外にします。クライアントが例外から回復するために何もできない場合は、チェックされていない例外にします

「スローする例外のタイプ」の核心は（ある程度）セマンティックであり、上記の引用は優れたガイドラインを提供します（したがって、C＃がチェックされた例外を取り除いたという概念に私はまだ驚いています-特にLiskovが主張するように）それらの有用性）。

残りは論理的になります。コンパイラはどの例外に対して明示的に応答することを期待していますか？クライアントが回復すると予想されるもの。

最後の質問に答えるには（他の人は上で完全に回答しているように見えます）、「正確な例外を泡立たせるか、例外を使用してマスクする必要がありますか？」

私はあなたがこのようなものを意味すると仮定しています：

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

いいえ、常に最も正確な例外、またはそのリストを宣言してください。メソッドをスロー可能として宣言する例外は、メソッドと呼び出し元の間のコントラクトの一部です。スロー"FileNotFoundException"とは、ファイル名が無効であり、ファイルが見つからない可能性があることを意味します。発信者はそれをインテリジェントに処理する必要があります。投げるExceptionということは、「ねえ、たわごとが起こります。取り引き」です。とても貧しいAPIです。

最初の記事のコメントには、「throws Exception」が有効で妥当な宣言であるいくつかの例がありnormalますが、これは、これから作成するほとんどの「」コードには当てはまりません。

ランタイム例外：ランタイム例外は、チェックされていない例外と呼ばれます。他のすべての例外はチェック例外であり、java.lang.RuntimeExceptionから派生しません。

チェック例外：チェック例外は、コードのどこかでキャッチする必要があります。チェックされた例外をスローするメソッドを呼び出しても、チェックされた例外をどこかでキャッチしない場合、コードはコンパイルされません。これがチェック例外と呼ばれる理由です。コンパイラは、それらが処理または宣言されていることを確認してチェックします。

Java APIのいくつかのメソッドはチェック済み例外をスローするため、自分で記述していないメソッドによって生成された例外に対処するために、例外ハンドラーを作成することがよくあります。

なぜ彼らは例外が浮上するのですか？エラーをより早く処理しないのですか？なぜ泡立ちますか？

たとえば、クライアントサーバーアプリケーションがあり、クライアントが見つけられなかったリソースまたは何か他のエラーを要求したとします。ユーザー要求の処理中にサーバー側で発生した可能性があるエラーの場合、それが義務です。サーバー側でクライアントが要求したものを取得できなかった理由をクライアントに通知するため、サーバー側でそれを達成するために、飲み込んだり処理したりする代わりに、throwキーワードを使用して例外をスローするようにコードが記述されます。その場合、どのエラーが発生したかをクライアントに知らせる機会はありません。

注：発生したエラーの種類を明確に説明するために、独自のExceptionオブジェクトを作成してクライアントにスローできます。

チェックされた例外は、外部ライブラリを使用する開発者にとって、例外的な状況でそのライブラリのコードに問題が発生する可能性があることを思い出させるものだと思います。

チェックされた例外とチェックされていない例外の詳細については、http：//learnjava.today/2015/11/checked-vs-unchecked-exceptions/をご覧ください。

チェックされた例外をまったく使用しない理由を追加したいだけです。これは完全な答えではありませんが、あなたの質問の一部を解決し、他の多くの答えを補完すると思います。

チェックされた例外が関係するときはいつでもthrows CheckedException、メソッドシグネチャのどこかにあります（CheckedExceptionチェックされた例外である可能性があります）。シグネチャは例外をスローしません。例外のスローは実装の一側面です。インターフェース、メソッドシグネチャ、親クラス、これらすべてのものは、それらの実装に依存するべきではありません。ここでチェックされた例外の使用法（実際throwsにはメソッドシグネチャでを宣言する必要があるという事実）は、上位レベルのインターフェイスをこれらのインターフェイスの実装にバインドしています。

例を挙げましょう。

このような素敵でクリーンなインターフェースを作ってみましょう

public interface IFoo {
    public void foo();
}

foo()次のように、methodの多くの実装を書くことができます

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

クラスフーは完全に元気です。それではクラスバーで最初の試みをしましょう

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

このクラスバーはコンパイルされません。InterruptedExceptionはチェックされた例外であるため、（メソッドfoo（）内でtry-catchを使用して）キャプチャするか、それをスローすることを宣言する（throws InterruptedExceptionメソッドシグネチャに追加する）必要があります。ここでこの例外をキャプチャしたくないので（他の場所で適切に処理できるように上方向に伝播させたい）、シグネチャを変更しましょう。

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

このクラスバーもコンパイルされません！署名が異なるため、Barのメソッドfoo（）はIFooのメソッドfoo（）をオーバーライドしません。@Overrideアノテーションを削除することもできますが、IFooのようなインターフェイスに対してプログラムを作成し、IFoo foo;後で、使用する実装を決定したいと思いfoo = new Bar();ます。Barのメソッドfoo（）がIFooのメソッドfooをオーバーライドしない場合、foo.foo();それを実行しても、Barのfoo（）の実装は呼び出されません。

バーのpublic void foo() throws InterruptedExceptionオーバーライドIFoo を作成するpublic void foo()にはthrows InterruptedException、IFooのメソッドシグネチャに追加する必要があります。ただし、これはfoo（）メソッドのシグネチャがIFooのメソッドシグネチャとは異なるため、Fooクラスで問題を引き起こします。さらに、throws InterruptedExceptionFooのメソッドfoo（）に追加した場合、Fooのメソッドfoo（）が、InterruptedExceptionをスローするが、InterruptedExceptionをスローしないことを宣言していることを示す別のエラーが発生します。

ご覧のとおり（私がこのことを説明するのにまともな仕事をした場合）、InterruptedExceptionのようなチェック例外をスローしているという事実は、インターフェイスIFooをその実装の1つに結び付けることを強制し、それがIFooに混乱を引き起こします。他の実装！

これは、チェックされた例外が悪い理由の1つです。キャップ。

1つの解決策は、チェックされた例外をキャプチャし、チェックされていない例外にラップして、チェックされていない例外をスローすることです。

• Javaは、例外の2つのカテゴリー（チェックありとチェックなし）を区別します。
• Javaは、チェック例外のキャッチまたは宣言された要件を適用します。
• 例外のタイプは、例外をチェックするかどうかを決定します。
• subclassesクラスの直接的または間接的なすべての例外タイプRuntimeException は、チェックされていない例外です。
• クラスから継承するが、クラスから継承しExceptionないすべてのクラスRuntimeExceptionは、と見なされますchecked exceptions。
• クラスErrorから継承するクラスは、チェックされていないと見なされます。
• コンパイラは、各メソッドの呼び出しと減速をチェックして、メソッドがスローするかどうかを判断しchecked exceptionます。
  • その場合、コンパイラーは例外が確実にキャッチされるか、throws節で宣言されるようにします。
• catch-or-declare要件のdeclare部分を満たすには、例外を生成するメソッドがthrowsを含む句を提供する必要がありますchecked-exception。
• Exception クラスは、キャッチまたは宣言するのに十分重要であると見なされたときにチェックされるように定義されます。

これは、決定に役立つ簡単なルールです。これは、Javaでのインターフェースの使用方法に関連しています。

あなたのクラスを取り、インターフェイスがクラスの機能を記述するが、（インターフェイスがそうであるように）基礎となる実装のどれも記述しないように、そのインターフェイスを設計することを想像してください。おそらく、別の方法でクラスを実装する可能性があると仮定します。

インターフェースのメソッドを見て、それらがスローする可能性のある例外を検討します。

例外がメソッドによってスローされる可能性がある場合、基礎となる実装に関係なく（つまり、機能のみを説明している場合）、インターフェイスのチェックされた例外である可能性があります。

基礎となる実装が原因で例外が発生した場合、それはインターフェースに存在してはなりません。したがって、それはクラスのチェックされていない例外であるか（チェックされていない例外はインターフェイスシグネチャに表示される必要がないため）、それをラップして、インターフェイスメソッドの一部であるチェックされた例外として再スローする必要があります。

ラップして再スローする必要があるかどうかを判断するには、インターフェイスのユーザーが例外条件をすぐに処理する必要があるのが理にかなっているのか、または例外が一般的すぎて何もすることができず、それを実行する必要があるのか​​を再度検討する必要がありますスタックを伝播します。ラップされた例外は、定義している新しいインターフェイスの機能として表現される場合に意味がありますか、それとも、他のメソッドでも発生する可能性のあるエラー状態のバッグの単なるキャリアですか？前者の場合、それはまだチェック済み例外である可能性があり、そうでない場合はチェック解除する必要があります。

通常、「バブルアップ」例外（キャッチアンドスロー）を計画する必要はありません。例外は、呼び出し元によって処理されるか（この場合はチェックされます）、または高レベルのハンドラーに到達する必要があります（この場合、チェックされていない場合が最も簡単です）。

コードでチェックされた例外をスローし、catchが数レベル上にある場合、あなたとcatchの間の各メソッドのシグネチャで例外を宣言する必要があることを指摘するだけです。したがって、throwのパスにあるすべての関数は、その例外の詳細を認識している必要があるため、カプセル化は壊れています。

つまり、上記のモジュールが実行時に処理することになっている例外は、チェック例外と呼ばれます。その他は、RuntimeExceptionまたはのチェックされていない例外Errorです。

このビデオでは、Javaのチェックされた例外とチェックされていない例外について説明しています：https :
//www.youtube.com/watch?v=ue2pOqLaArw

これらはすべてチェック例外です。チェックされていない例外は、RuntimeExceptionのサブクラスです。決定はそれらをどのように処理するかではなく、コードがそれらをスローするかどうかです。コンパイラーが例外を処理していないことを知らせたくない場合は、チェックされていない（RuntimeExceptionのサブクラス）例外を使用します。これらは、メモリ不足エラーなど、回復できない状況のために保存する必要があります。

チェックされた例外を嫌う別の証拠を誰かが気にかけている場合は、人気のあるJSONライブラリの最初の数段落を参照してください。

「これはチェックされた例外ですが、ほとんど回復できません。ほとんどの呼び出し元は、この例外をチェックされていない例外にラップして再スローするだけです。」

では、代わりに「単純にそれをラップする」べきなら、なぜ誰もが開発者に例外をチェックさせ続けるのはなぜでしょうか？笑

http://developer.android.com/reference/org/json/JSONException.html

チェックされた例外：

• 実行時にプログラムがスムーズに実行されるようにコンパイラーによってチェックされる例外は、チェック例外と呼ばれます。

• これらはコンパイル時に発生します。

• これらが適切に処理されない場合、コンパイル時エラー（例外ではない）が発生します。

• RuntimeExceptionを除くExceptionクラスのすべてのサブクラスは、チェック済み例外です。

  仮説の例 -家を出て試験に出かけるとしますが、自宅でホールチケットを受け取ったかどうかを確認すると（コンパイル時）、試験ホールでは問題は発生しません（実行時）。

未チェックの例外：

• コンパイラによってチェックされない例外は、チェックされない例外と呼ばれます。

• これらは実行時に発生します。

• これらの例外が適切に処理されない場合、コンパイル時エラーは発生しません。ただし、プログラムは実行時に途中で終了します。

• RunTimeExceptionおよびErrorのすべてのサブクラスは、チェックされない例外です。

  仮説の例 -あなたが試験会場にいるが、どういうわけかあなたの学校は火災事故（実行時の手段）を起こしていて、その時点では何もできず、事前に（コンパイル時に）予防策をとることができるとします。

すべての例外は、チェックされた例外でなければなりません。

1. 未チェックの例外は無制限のgotoです。そして、無制限のゴトは悪いものと考えられています。

2. 未チェックの例外はカプセル化を壊します。これらを正しく処理するには、スローアーとキャッチャーの間の呼び出しツリー内のすべての関数が、バグを回避するために認識されている必要があります。

3. 例外は、例外をスローする関数のエラーですが、それらを処理する関数のエラーではありません。例外の目的は、プログラムがエラーであるかどうかの決定を別のコンテキストに遅らせることにより、プログラムにもう一度チャンスを与えることです。正しい判断を下せるのは、他の状況でのみです。