Javaの例外クラスは、大きく3つ(Errorを継承したクラス、チェック例外、非チェック例外)に分けることができ、すべてThrowableを継承しています
この中でも、ErrorとRuntimeExceptionおよびそれらを継承するものは例外処理が任意で、「非チェック例外」と呼びます。
非チェック例外を除いた残りの例外クラスは全て例外処理が必須で、「チェック例外」と呼びます。
さらに、例外処理に関して分類すると、
非チェック例外の中でも、Errorを継承したものは、JVMやOSに依存するエラーであり、正常なプログラムであっても、いつでも発生する可能性があり、発生後にプログラムの中でハンドリングすることは困難です。
一般に、例外処理のコードは追加しません。
同じく非チェック例外である、RuntimeExceptionを継承する実行時例外は、デバッグ済みのプログラムであれば発生しないであろうものです。
通常、非チェック例外と言ったときには、これを指しますが、イレギュラーなものとしてSQLExceptionも非チェック例外です。これは、データベース側でシステム系のエラーが起きた場合に、アプリ側で対処不可能なのでErrorを継承した例外と思いきや、Exceptionを継承した非チェック例外となっています。
SQLExceptionがスローされると、コネクションプールを使用していれば、ガーベッジコレクションされるまでコネクションが1つ利用できなくなり、ケースによっては、リソースが開放されずにOutOfMomoryErrorでアボートしてしまう危険性があるので、非チェック例外ですが、エラーハンドリングが必須です。
一方、チェック例外は、コンパイル時に例外処理が実装されているかどうか検査され、含んでいない場合はコンパイルエラーとします。
新規の例外クラスを追加する場合、例外処理によって例外的事象から回復したい場合は、Exceptionを継承して作ります。特に、非チェック例外としたい場合は、RuntimeExceptionを継承します。

この中でも、ErrorとRuntimeExceptionおよびそれらを継承するものは例外処理が任意で、「非チェック例外」と呼びます。
非チェック例外を除いた残りの例外クラスは全て例外処理が必須で、「チェック例外」と呼びます。
さらに、例外処理に関して分類すると、
非チェック例外の中でも、Errorを継承したものは、JVMやOSに依存するエラーであり、正常なプログラムであっても、いつでも発生する可能性があり、発生後にプログラムの中でハンドリングすることは困難です。
一般に、例外処理のコードは追加しません。
同じく非チェック例外である、RuntimeExceptionを継承する実行時例外は、デバッグ済みのプログラムであれば発生しないであろうものです。
通常、非チェック例外と言ったときには、これを指しますが、イレギュラーなものとしてSQLExceptionも非チェック例外です。これは、データベース側でシステム系のエラーが起きた場合に、アプリ側で対処不可能なのでErrorを継承した例外と思いきや、Exceptionを継承した非チェック例外となっています。
SQLExceptionがスローされると、コネクションプールを使用していれば、ガーベッジコレクションされるまでコネクションが1つ利用できなくなり、ケースによっては、リソースが開放されずにOutOfMomoryErrorでアボートしてしまう危険性があるので、非チェック例外ですが、エラーハンドリングが必須です。
一方、チェック例外は、コンパイル時に例外処理が実装されているかどうか検査され、含んでいない場合はコンパイルエラーとします。
新規の例外クラスを追加する場合、例外処理によって例外的事象から回復したい場合は、Exceptionを継承して作ります。特に、非チェック例外としたい場合は、RuntimeExceptionを継承します。