Java例外の根拠

Question

今回はかなり理論的な質問です。だから私は、Eclipseで、この機能を使用しています：「未処理の例外型にFileNotFoundException」ために実行することはできません

CsvReader csv = new CsvReader("src/maindroite.csv"); 

。私は、ファイルが存在しない場合に何かを追加しなければならないことを理解しています。その時点で、通常、例外をキャッチして放棄するためにいくつかの行を追加します。しかし、私の質問です：なぜファイルが存在する場合でも例外をキャッチする必要があります？そして、実際には、私はなぜこの例外をいくつかの関数に持たせ、他にはないのですか？

たとえば、のは、私が実行しようとしているとしましょう：

"square.jpg" が存在する

ImageIcon icon1 = new ImageIcon("src/square.jpg"); 
ImageIcon icon2 = new ImageIcon("src/circle.jpg"); 

ではなく、 "circle.jpgを"。アイコン1は作成できませんが、アイコン2は作成されません。しかし、画像が存在しない場合にExceptionHandlerを追加する必要はありません。両方の機能の違いは何ですか？

それを合計するには、次の

• をなぜ私は、ファイルがが存在しないときexceptionHandlerのを追加する必要がありますか？
• なぜいくつかの関数にはExceptionHandlerを追加する必要がありますか？

ありがとう！

Answer 1

は、なぜ私は、ファイルが存在しないときexceptionHandlerのを追加する必要がありますか？

基本的には、条件付きコードを書くことができないため、関係なく追加する必要があります。つまり、ファイルが存在するかどうかをコンパイラが知ることはできません。 FileNotFoundExceptionがchecked例外であるため、try/catchブロックを配置してください。

なぜ、いくつかの関数にはExceptionHandlerを追加する必要がありますか？

あなたが唯一のチェック例外をスローするものにtry/catchブロックを追加する必要があり、それはRuntimeExceptionまたはErrorクラスから* *ありません*継承を行うものです。ErrorとRuntimeExceptionのサブクラスはチェック例外ではなく、try/catchを置いても構わないし、コンパイラが気にしないでもかまいません。 ImageIconのコンストラクタは何らかの例外をスローしないため、画像が存在しない場合はnullを返すだけで、try/catchブロックを実行する必要はありません。ファイルは、[ES]が存在しないとき*

Answer 2

ファイルが存在していても、システム上にファイルが存在しないことがあります。または、src/square.jpgを持たない人にこのコードを渡すことができます。ハードドライブ上の何かが壊れて誤ってsrc/square.jpgが削除されるなど、ハードウェアの誤動作が起こる可能性があります。たぶんユーザーはファイルを削除するだけかもしれません。あなたが本当に悪い何かが起これば、最悪の場合には何が起こるかを考えるためのJava力の

例外処理（のようなsrc/square.jpgが行方不明になります）。あなたはクラッシュしますか？何も起こらなかったように続けるのは大丈夫ですか？ catch節でこれらの障害モードを処理する方法を決定することになります。あなたが合理的に処理するために期待できる機能で間違って行くことができる何が本当にありませんので

いくつかの関数は例外を処理する必要はありません。

Answer 3

1）なぜ私はexceptionHandlerのを追加する必要がありますか？

Javaコンパイラは、そのファイルが任意の実行時に実際に存在するかどうかを知ることができないためです。 （コンパイルした後、プログラムを実行する前にファイルが削除されたとします）基本的に、コードには常に起こるとは予想されないが、とにかく可能性のある条件を処理するために必要なロジックが必要です。

2）なぜいくつかの関数にはExceptionHandlerを追加する必要がありますか？

さまざまな理由が考えられますが、ここにはあなたが見ているものがあります。メソッドごとに例外がスローされますが、try/catchブロックごとに捕捉されます。あなたの例では、あなたが何をしたいかに応じて、一緒に独自のtry/catchブロックまたは両方にImageIconコンストラクタの各呼び出しをラップすることができます：に比べ

try { 
    icon1 = new ImageIcon("f1.jpg"); 
} catch (Exception e) { /* Handle the case for missing "f1.jpg". */ } 
try { 
    icon2 = new ImageIcon("f2.jpg"); 
} catch (Exception e) { /* Handle the case for missing "f2.jpg". */ } 

：

try { 
    icon1 = new ImageIcon("f1.jpg"); 
    icon2 = new ImageIcon("f2.jpg"); 
} catch (Exception e) { /* Handle the case for missing "f1" or "f2". */ } 

Answer 4

をので、 Javaでは、「チェックされた」例外と「チェックされていない」例外が区別されます。チェックされていない例外が存在するかどうか、そしてAPIメソッドが例外をスローする必要があるかどうかについては、多くの論争の源です。ジャワによると

はトレイル：

ここでは一番下の行のガイドラインです：クライアントが合理的チェック例外作る、例外から回復する を期待することができます。 クライアントが例外から回復するために何もできない場合は、 未確認の例外にします。

これは、いわゆる理論的根拠です。

「論争」hereについてさらに読む。

Answer 5

ファイルが存在する場合、なぜExceptionHandlerを追加する必要がありますか？

今のところ存在していますが、毎回保証はありません。理由の多くのために起こる可能性があります。ファイルがない場合、InputStreamと関連するビジネスロジックを実行する意味がなく、ビジネスが成功しないと確信しています。

なぜいくつかの関数にはExceptionHandlerを追加する必要がありますか？

Imageiconのような一部のクラスは、ビジネス処理のストッパーを表示しません。彼らがそこにいなければ、それはあなたのコアビジネスロジックを続けることができます。

これは、一部のクラスが例外を要求し、一部が例外であることが主な理由だと私は感じています。

Answer 6

チェックされた例外の背後にあるアイデアは、関数の呼び出し元が例外からどのような例外を逃れる可能性があるかを知ることができるという点です。実際にFileNotFoundExceptionをキャッチする必要はありません。その場合、メソッドシグネチャにthrows FileNotFoundExceptionを追加して、そのような例外がメソッドから逃げる可能性があることを発信者に知らせることができます。

概念は良いですが、残念ながら、過度に重大ではないすべての例外をキャッチし、それらを呼び出し元の共通の例外タイプにまとめたいという簡潔な方法はありません。多くの場合、例外が発生した場合、伝えたい実際のメッセージは「メソッドは完了していませんが、システムは起動しておらず、副作用が取り消されている」か、 「この方法は完了せず、システムは発火していないようだが、他の副作用があったかもしれない」例外が捕捉され、上記のフォーマットの1つにラップされるべきコードの領域を示すための簡潔な構文があったとしても、役立つでしょう。