この記事では、Javaの例外メカニズムの概念に焦点を当てています。この記事を書く目的は、長い間これらのことを思い出すように促進することです。
1。例外メカニズム
1.1例外メカニズムとは、エラーが発生したときにプログラムがどのように処理するかを指します。具体的には、例外メカニズムは、プログラムの出口に安全なチャネルを提供します。エラーが発生すると、プログラム実行のプロセスが変更され、プログラムの制御が例外プロセッサに転送されます。
1.2例外に対処する従来の方法は、関数が特別な結果を返して、例外が発生することを示すことです（通常、この特別な結果は一般的にそのように知られています）。これには次の欠点があります。たとえば、関数が-1を返す場合、例外が発生することを意味しますが、関数が-1の正しい値を返したい場合、混乱します。読みやすさは低下し、プログラムコードは例外を処理するコードと混合されます。関数を呼び出すプログラムは、エラーを分析します。これにより、クライアントプログラマーはライブラリ機能を深く理解する必要があります。
1.3例外処理プロセス
1.3.1エラーが発生した場合、メソッドはすぐに終了し、値を返しません。同時に、例外オブジェクトがスローされます。
1.3.2このメソッドを呼び出すプログラムは引き続き実行されませんが、例外を処理してそのコードを実行できる例外ハンドラーを検索します。
2例外の分類
2.1例外の分類
2.1.1例外の継承構造：ベースクラスはスロー可能であり、エラーと例外継承はスロー可能、runtimeexception、およびioexceptionなどであり、特定のruntimeexceptionはruntimeexceptionを継承します。
2.1.2エラーとruntimeexceptionとそのサブクラスは、チェックされていない例外になり、その他の例外はチェックされた例外になります。
2.2各タイプの例外の特性
2.2.1エラーシステムエラークラスシステムは、Javaオペレーティングシステムの内部エラーとリソースの疲労を説明します。アプリケーションは、このタイプのオブジェクトを投げるべきではありません（通常、仮想マシンでスローされます）。そのようなエラーが発生した場合、プログラムを安全に終了しようとする以外に、他にできることはありません。したがって、プログラミングを設計するときは、例外システムにもっと注意を払う必要があります。
2.2.2例外システム例外システムには、runtimeExceptionシステムおよびその他の非runtimeexceptionシステムが含まれます
2.2.2.1 runtimeexception runtimeexceptionシステムには、間違ったタイプ変換、アレイアウトバウンドアクセス、ヌルポインターへのアクセスの試みなどが含まれます。runtimeexceptionの処理の原則は次のとおりです。たとえば、アレイアウトバウンドアクセスの例外は、配列のサブスクリプトと配列の境界をチェックすることで回避できます。
2.2.2.2その他の（IOExceptionなど）このような例外は、一般に、ファイルの最後からデータを読み取ろうとするなどの外部エラーです。これはプログラム自体のエラーではなく、アプリケーション環境で発生する外部エラーです。
2.3 C ++例外分類との違い
2.3.1実際、JavaのRuntimeExceptionのクラス名は適切ではありません。これは、実行時に例外が発生するためです。 （コンピレーション中に発生するエラーは例外ではありません。つまり、例外は、プログラムの実行中に発生するエラーを解決することです）。
2.3.2 C ++のLogic_ErrorはJavaのRuntimeexceptionと同等ですが、Runtime_ErrorはJavaの非runtimeexceptionタイプの例外と同等です。
3.例外の使用方法
3.1メソッドを宣言して例外をスローします
3.1.1構文：スロー（省略）
3.1.2なぜ例外をスローする方法を宣言する必要があるのですか？メソッドが例外をスローするかどうかは、メソッドの戻り値のタイプと同じくらい重要です。このメソッドが例外をスローすると仮定すると、メソッドが例外をスローすることを宣言していません。クライアントプログラマーは、例外を処理するためにコードを作成せずにこのメソッドを呼び出すことができます。次に、例外が発生したら、この例外を解決するための適切な例外コントローラーはありません。
3.1.3スローされた例外が必然的にチェックされた例外なのはなぜですか？ runtimeexceptionとエラーは、任意のコードで生成できます。プログラマーに投げられる必要はありません。エラーが発生すると、対応する例外が自動的にスローされます。チェックされた例外はプログラマーによってスローされます。これは2つの状況に分かれています。クライアントプログラマーは、例外をスローするライブラリ関数を呼び出します（ライブラリ関数の例外はライブラリプログラマーによってスローされます）。クライアントプログラマーは、スローステートメントを使用して自分で例外をスローします。エラーに遭遇すると、プログラマーは一般に無力です。 runtimeexceptionに遭遇した場合、プログラムに論理的なエラーがあり、プログラムを変更する必要がある必要があります（デバッグの方法に相当）。チェックされた例外のみがプログラマーが気にするものであり、プログラムはチェックされた例外のみをスローまたは処理する必要があります。
3.1.4注：親クラスの特定の方法をカバーするサブクラスメソッドは、親クラスの方法よりも多くの例外を投げることはできません。したがって、親クラスの方法を設計するときに、例外がスローされると宣言されることがありますが、メソッドを実装する実際のコードは例外をスローしません。これの目的は、サブクラス法を促進して、親クラスの方法を上書きすることです。
3.2例外をスローする方法
3.2.1構文：スロー（省略）
3.2.2どの例外がスローされますか？例外オブジェクトの場合、オブジェクトタイプは、例外がオブジェクトタイプの場合、例外オブジェクト自体が無意味である場合に非常に役立ちます。たとえば、例外オブジェクトのタイプがClassCastExceptionの場合、このクラス名は唯一の有用な情報です。したがって、どの例外をスローするかを選択するとき、最も重要なことは、例外の状況を明確に説明できる例外のクラス名を選択することです。
3.2.3通常、例外オブジェクトには2つのコンストラクターがあります。1つはパラメーターのないコンストラクターです。もう1つは文字列を備えたコンストラクターで、タイプ名に加えて、この例外オブジェクトの追加の説明として使用されます。
3.2.4独自の例外を作成する：Javaの組み込みの例外がない場合、例外の状況を明確に説明できない場合、独自の例外を作成する必要があります。唯一の有用なものはタイプ名情報であることに注意する必要があるため、例外クラスの設計にエネルギーを費やさないでください。
3.3例外をキャプチャする例外が処理されない場合、非グラフィカルインターフェイスプログラムの場合、プログラムは中止され、例外情報が出力されます。グラフィカルインターフェイスプログラムの場合、例外情報も出力されますが、プログラムは中止されませんが、ユーザーインターフェイス処理ループに戻ります。
3.3.1構文：トライ、キャッチ、最後に（省略）コントローラーモジュールは、トライブロックのすぐ後ろにある必要があります。例外がスローされた場合、例外コントロールメカニズムは、パラメーターが例外タイプと一致する最初のコントローラーを検索し、CATCH句を入力し、例外が制御されていると考えます。 Catch句が終了すると、コントローラーの検索も停止します。
3.3.1.1複数の例外をキャッチします（構文とキャプチャの順序に注意してください）（省略）
3.3.1.2最終的に（省略）の使用と例外処理プロセス
3.3.2例外処理は何をしますか？ Javaの場合、ゴミ収集により、例外処理ではメモリリサイクルは必要ありません。ただし、ファイル、ネットワーク接続、写真など、プログラマーが収集する必要があるリソースがまだいくつかあります。
3.3.3メソッドは例外を投げたり、メソッドの例外をキャッチする必要がありますか？原則：処理方法を知っている例外をキャッチして処理し、処理方法を知らない例外を渡す
3.3.4もう一度例外を投げます
3.3.4.1なぜもう一度例外を投げるのですか？このレベルでは、コンテンツの一部のみを処理でき、一部の処理はより高いレベルの環境で完了する必要があるため、例外を再度スローする必要があります。これにより、例外ハンドラーの各段階が処理できる例外を処理できます。
3.3.4.2同じトライブロックに対応するキャッチブロックは無視され、スローされた例外はより高いレベルに入ります。
4例外に関するその他の質問
4.1使い捨て例外まず、例外を使用するのは非常に便利です。そのため、プログラマーは通常、エラーを処理するためにコードを作成することを望まないが、単に例外をスローすることです。これは間違っています。完全に既知のエラーの場合、プログラムの堅牢性を高めるために、そのようなエラーを処理するコードを書き込む必要があります。さらに、異常なメカニズムの効率は非常に貧弱です。
4.2例外を通常のエラーから分割します。通常のエラーの場合、プログラムの堅牢性を高めるために、そのようなエラーを扱うコードを書き込む必要があります。例外は、外部の未定で予測されたランタイムエラーにのみ必要です。
4.3例外オブジェクトに含まれる情報一般的に言えば、例外オブジェクトの唯一の有用な情報はタイプ情報です。ただし、例外文字列コンストラクターを使用する場合、この文字列は追加情報として使用することもできます。 getMessage（）、toString（）、またはprintStacktrace（）を呼び出して、例外オブジェクトのメソッドは、それぞれ追加情報、クラス名、および通話スタック情報を取得できます。後者には、前者のスーパーセットである情報が含まれています。
一般的に使用される例外：
UnsportedoperationExceptionによってサポートされていない操作
IllegalargumentException違法パラメーター
indexoutofboundsexceptionインデックスアウトバウンド
IllegalStateException違法状態
異常な警告と通常の警告には一定の違いがあります。アプリケーションで例外が発生すると、実行プログラムの通常の指示の流れが中断されます。つまり、例外が発生した後のコードは正しく実行されません。データベースロールバック操作をトリガーします。
Java開発プラットフォームでは、例外には事前定義された例外とカスタム例外が含まれます。これらの2種類の例外は互いに補完します。資格のあるプログラム開発者として、アプリケーションで例外を使用するのが得意です。これにより、アプリケーションの互換性が向上します。同時に、アプリケーションの通常の動作を確保するための前提条件でもあります。したがって、例外処理は、優れたアプリケーションを開発するために非常に重要です。このため、著者は、プログラム開発者がJavaアプリケーションで一般的な例外を深く理解する必要があると考えています。これらの一般的な例外を理解した場合にのみ、カスタムの例外をうまく処理できます。
1。一般的な例外のタイプと原因。
Javaアプリケーションの一般的な例外に関して、著者は、プログラム開発者が2つの側面からそれらを理解する必要があると考えています。まず、一般的なJavaアプリケーションの例外があるかを知る必要があり、次に、この例外が原因である原因を知る必要があります。これには、プログラムマネージャーが日常業務の蓄積に注意を払う必要があるだけでなく、必要に応じて他のチャネルから情報を収集する必要があります。著者は、すべてのプログラム開発者にとって何らかの助けになることを期待して、これについて分析を実施します。
1。SQLEXCEPTION：データベース例外クラスを操作します。
今日のJavaアプリケーションのほとんどは、実行するためにデータベースに依存しています。 Javaアプリケーションがデータベースと通信するときにエラーが発生した場合、このクラスはトリガーされます。同時に、このクラスを通じてデータベースエラー情報がユーザーに表示されます。言い換えれば、この操作データベース例外クラスは、データベースとユーザーの間に例外情報を送信するためのブリッジです。たとえば、ユーザーはシステムにデータを挿入し、特定のフィールドがデータベースで一意でなければならないことを規定しています。ユーザーがデータを挿入すると、このフィールドの値が既存のレコードで繰り返されると、データベースの一意性制約に違反し、データベースから例外メッセージがリリースされます。この情報は、データベースレベルで発生するため、ユーザーには表示されない場合があります。この時点で、この操作データベース例外クラスは、データベースの例外情報をキャプチャし、例外情報を前景に渡します。このようにして、フロントデスクユーザーは、この例外情報に基づいてエラーの原因を分析できます。これは、この操作データベース例外クラスの主な目的です。 Javaアプリケーションでは、すべてのデータベース操作が例外が発生すると、このクラスがトリガーされます。 Javaアプリケーション自体のすべての迅速な情報は、現時点では一般的すぎることが多く、データベースとの相互作用にエラーがあり、参照値があまりないと言っているだけです。現時点では、データベースのプロンプト情報がより価値があります。
2。ClassCastException：データ型変換例外。
Javaアプリケーションでは、データ型を変換する必要がある場合があります。この変換には、表示された変換と暗黙的な変換が含まれます。ただし、どのように変換しても、前提条件、つまりデータ型の互換性を満たす必要があります。データ変換プロセス中にこの原則に違反した場合、データ型変換の例外がトリガーされます。たとえば、アプリケーションでは、開発者はデータベースで受け入れられる可能性のあるデートタイプのデータに文字型の日付データを変換する必要があります。現時点では、彼らはそれを前景アプリケーションで制御するだけで、一般的に問題はありません。ただし、フォアグラウンドアプリケーションに関連するコントロールがない場合、ユーザーは日付を入力するときに月と日の情報を入力するだけでなく、年の情報がありません。この時点で、アプリケーションがデータ型変換を実行すると例外が表示されます。私の経験によれば、データ型の変換の例外により、アプリケーション開発でより多くの例外が発生し、比較的低レベルの例外も発生します。ほとんどの場合、アプリケーションウィンドウでデータ型に対する強制制御を実行できるためです。つまり、データ型が変換される前に、データ型の互換性が確保されます。この場合、データ型の変換の例外を引き起こすことは容易ではありません。数値タイプのみを許可するフィールドで、入力が許可されていない数値以外の文字を設定することができます。例外処理メカニズムを使用すると、アプリケーションは誤って実行されません。ただし、実際の開発では、エラーの原因を可能な限り予測し、異常を避けようとする必要があります。
3。numberformatexception：文字列が数値タイプに変換されたときにスローされる例外。
データ型変換プロセス中、数値変換への文字変換のプロセス中に発生する問題である場合、Javaプログラム、つまりNumberformatexceptionで独立した例外が使用されます。たとえば、文字型データ「123456」が数値データに変換されると、許可されます。ただし、文字タイプのデータに123＃56などの非数値文字が含まれている場合、数値型に変換されると例外が表示されます。システムはこの例外をキャッチし、処理します。
Javaアプリケーションには多くの一般的な例外クラスがあります。対応するクラスの例外が見つからない場合、いくつかのクラスの例外にアクセスすることは許可されていません。ファイルは例外を終了し、ファイルは例外が見つかりませんでした。フィールドには例外が見つかりませんでした。一般に、システム開発者はこの例外名に基づいて現在の例外のタイプを判断できます。それは良いことですが、良い記憶は悪いペンほど良くありません。必要に応じて（特にカスタム例外がある場合）、プログラム開発者は最終的に例外リストを手元に置いています。この場合、アプリケーションがデバッグ中に問題を発見したり、操作中にユーザーから苦情を受け取ったりするかどうかにかかわらず、例外名に基づいて例外の原因を見つけることができます。これにより、例外を最短時間で解決し、アプリケーションの通常の動作を回復させることができます。この尺度は長年使用されており、非常に効果的です。
2。例外管理のための実用的な提案。
データベースの例外を操作するために、Javaアプリケーションは1つの例外クラスのみを提供します。したがって、Javaアプリケーションのエラー情報のみに依存することは、アプリケーション担当者がエラーの原因を排除するのに役立つことがよくあります。この例外がアプリケーションエラーまたはデータベースエラーによって引き起こされるかどうかのみを指定できます。問題の原因をさらに指定するために、データベースレベルで例外を定義する際に特定の原因を説明することが最善です。たとえば、フォアグラウンドアプリケーションは、データベースの機能または手順を呼び出す場合があります。現時点では、データベース関数またはプロセスで良い仕事をすることで、特定の例外の特定の原因を説明できます。たとえば、特定の基本テーブルに基づいて別のテーブルを生成する場合、特定のフィールドは空にすることはできません。これらの例外情報を明確に説明した後、同様の例外が実際に遭遇した場合、データベース例外クラスを操作すると、データベース例外情報がフロントエンドユーザーに逆転します。これにより、ユーザーは問題の原因を見つけ、最短時間で修正できます。もちろん、これにはJavaプログラマーとデータベースデザイナーとの調整が必要です。
第二に、例外は標準ではないことに注意する必要があります。言い換えれば、ほとんどの異常は、前提の合理的な先見性と予防によって排除される可能性があります。 4ポイント操作に設計されている場合、アプリケーション操作中に可能な例外を排除するために、フォアグラウンドアプリケーションウィンドウのEX番号フィールドに0値を入力する値を制限できます。ただし、これには多くの場合、アプリケーション開発者は豊富な実務経験を持ち、厳格な思考論理を持つ必要があります。これは困難ですが、著者は、プログラム開発者が常にユーザーをお客様の声として、ユーザーがアプリケーションのデザインバグを発見できるようにするのではなく、この点で一生懸命働くべきだと考えています。著者は、プログラマーの制御を超えているいくつかの要因の場合にのみ、例外が投げられることが許可されると考えています。アプリケーション開発者がこのエラーを認識できるが、それでもこの異常を防ぐために効果的な措置を講じない場合、著者はそれを許可しません。
arithmeticexception（除数0の例外）、バッファーフルーエクセプション（バッファーオーバーフロー例外）、バッファーフルーエクセプション（バッファーアンダーフロー例外）、indexoutofboundsexception（nullpointerexception（nullpointerexception）、emptystackexception（空のスタック例外） negativearraysizeexception、nosuchelementexception、secutionexception、systemexception、undeclared throwableexception
1。Java.lang.nullpointerexception
例外の説明は、「プログラムがヌルポインターに遭遇する」です。簡単に言えば、存在しない無知のオブジェクトまたは存在しないオブジェクトを呼び出すこと、つまり配列の初期化を配列要素の初期化と混同することを意味します。配列の初期化は、必要なスペースを配列に割り当てることです。初期化された配列の要素はインスタンス化されておらず、まだ空です。そのため、各要素を初期化する必要があります（呼び出したい場合）
2。java.lang.classnotfoundexception
例外の説明は「指定されたクラスは存在しません」です。
3。Java.lang.arithmeticexception
この例外の説明は「数学的操作例外」です。たとえば、ゼロで割るような操作がプログラムに表示される場合、そのような例外が発生します。
4。Java.lang.arrayindexOutofboundsexception
例外の説明は「アレイのサブスクリプトは範囲外です」です。現在、ほとんどのプログラムには配列の操作があります。したがって、アレイを呼び出すときは、慎重にチェックして、呼び出すサブスクリプが配列の範囲を超えているかどうかを確認する必要があります。一般的に言えば、ディスプレイ（つまり、定数をサブスクリプトに直接使用する）呼び出しを呼び出すことでそのような間違いを犯すことは容易ではありませんが、暗黙的（つまり、変数を使用してサブスクリプトを表す）はしばしば間違いを犯します。プログラムで定義されている配列の長さが特定の特定の方法によって決定され、事前に宣言されない別の状況があります。現時点では、この例外を回避するために、最初にアレイの長さを確認するのが最善です。
5。java.lang.illegalargumentexception
この例外の説明は、メソッドg.setcolor（int red、int green、int blue）の3つの値など、「メソッドのパラメーターエラー」です。 255以上がある場合、この例外も発生します。したがって、この例外が見つかったら、私たちが行う必要があるのは、メソッド呼び出しでパラメーターにエラーが渡されるかどうかをすばやく確認することです。
6。Java.lang.illegalaccessexception
この例外の説明は「アクセス許可なし」です。この例外は、アプリケーションがクラスを呼び出したいときに発生しますが、現在の方法にはクラスへのアクセス権限がありません。プログラムでパッケージを使用する場合、この例外、例外、およびJavaに注意する必要があります
読んでくれてありがとう、私はそれがあなたを助けることができることを願っています。このサイトへのご支援ありがとうございます！