2017-02-02 4 views
-4

は、私はこのコードの些細な部分があると、実行時にリストのサイズは例外をキャッチする - なぜそれが必要ですか?

try{ 
    for(int i = 0; i < list.size(); i++){ 
     list.get(10); 
    } 

}catch(NullPointerException e){ 
     System.out.println(" exception to string :" + e.toString()); 
     System.out.println(" exception get class" + e.getClass()); 
     e.printStackTrace(); 
} 

4.だからJVMは、catchブロックでこれを実装することなく、境界の例外のうち、インデックスがスローされますです。

同様に、リストがnullの場合、JVMはNULLポインタ例外をスローします。

だから、なぜ、IndexOutOfBoundsExceptionまたはNullPointerExceptionを宣言しなければならないのでしょうか? catchブロックで一般的な例外を宣言するだけではどうですか?このアプローチのメリットとデメリットは何ですか?

+2

https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html –

+0

実際にコード内でいくつかの例外を修正することができます。たとえば、ソケットに書き込むときにIOExceptionで実行すると、再接続シーケンスを開始してもう一度やり直すことができます... – Fildor

+0

ユーザーにカスタムメッセージを送信しています。ここには理由がある – lechonex

答えて

2

通常、修正する必要があるコードのバグを示すことが多いため、一般的な例外をコード内のどこかに置くべきではありません。

外部リソースに関連するチェック例外(IOExceptionなど)の中にはコントロール内にないものがあるため、それらをキャッチして対応する必要がありますが、NullPointerExceptionsやIndexOutOfBoundExceptionは避けてください。

2

基本的に2つのタイプの例外があります:チェックされているかチェックされていません。チェック例外を宣言またはキャッチする必要がありますが、チェックされていない例外についてはこれを行う必要はありません。

違いは何ですか?多くの場合、誰が使用しているかによって異なりますが、一般的には次のようになります。

  • 最終的に間違っていると思われるものについては、例外がスローされます。 IOExceptionなど - 利用できないファイル(存在しない、ロックされていないなど)や書き込み可能なファイルは、決して発生しないものではなく、開発者が防止しようとする可能性があります。これらのことが間違っていると予想する必要があるので、チェックされた例外を使用して、メソッドのシグネチャを強制して、それらが間違っていると宣言するか、例外をキャッチしてケースを処理します。
  • チェックされていない例外は主に間違っていても間違ってはいけないものに使用されます。多くの場合、それらはプログラミングエラー(NullPointerExceptions、IndexOutOfBoundExceptionsなど)または予期しないシステム障害(データベースが利用できないなど)に起因します。とにかく期待されていないので、通常は明示的にキャッチしません。

オンまたはオフ例外が(例えばバブルアップ例外の多数をすることができることに依存しているので、チェック例外に国連未確認のものをラップする必要が図書館で)何か他のもののために使用されている状況があります言われていること。

シグネチャのキャッチ/宣言については、通常、チェック例外をできるだけ明示的に指定する必要があります。具体的には、SQLExceptionと異なるようにIOExceptionを処理するとよいでしょう。チェックされていない例外は、単に捕捉され、報告される(例えば、それらを記録または再利用することによって)かもしれないが、そのような場合でも、 EJBExceptionはEJBによってスローされ、実際のチェック例外のラッパーである可能性があります。したがって、それらをアンラップすることができます。

NullPointerExceptionの最終的な語句:最初に出てはいけないので、明示的にそれらをキャッチすることは決してありません(ヌルかそれらのものにアクセスする前にチェックしてください) tryブロック内でnullである可能性のあるもの(直接的に、呼び出されるメソッドで)は、妥当な反応を実現するのが難しいでしょう。そのような場合は、処理されていない例外(スレッドと同じように)をキャッチして開発者に報告し、問題を見て修正できるようにすることが最善です。

0

一般的なThrowable(つまり、すべてが間違っている可能性があることを意味する)ではなく、catchブロックでより具体的な例外を使用する理由を理解するために、ここに。

何年も実稼動中のソフトウェアを作成するときは、非常に頑強である必要があります。つまり、コードがどんな状況でも正常に処理できるようにするために、は何か問題が起きたとしてもを実行し続けます。

特定のコードでは、リストが短すぎることがよくあるかもしれませんが(ライブラリは時折誤っていることがあります)、listがnullの場合は致命的で予期しないエラーです。

最も簡単な方法は、例外階層の設計方法を使用し、異なるキャッチブロックを使用する方法です。

また、Java 7以降を使用する場合、処理コードが同じであっても元の例外を保持できるパイプ記号を使用して結合ブロックを作成できます。

関連する問題