Javaの例外クラスの学び方

Question

Javaについて勉強しているのですが、例外クラスのことがよく分からないでいます。

Javaの例外クラスを知るまで「エラーは『エラー』だ」と漠然と思っておりましたので、例外をクラスとして扱えたり、ましてや継承できたり、果ては独自の例外クラスを作ることができるというのが、とても新鮮で、 感覚的 によく分からないのです。

例えば、インスタンス化なら「new演算子を使うことでインスタンスが作られて、そのアドレスへの参照が変数に代入して～」といった感じに人に説明できますし、絵にも書くことができますが、例外クラスはまるでイメージできません。

特に厄介なのがthrows文で「『例外を呼び出し元に返す(呼び出し元で処理する)』ってどういうこと!?　例外を呼び出し元に戻り値として渡しているってこと!?」といった具合に混乱しております。

例外クラスは難しい処理(仕様?)なのでしょうか?
それとも理解への足掛かりとなる 気付き を見逃しているだけなのでしょうか?

皆さんは例外クラスをどのように理解されましたか?

ご回答のほど、よろしくお願いします。

Answer 1

例外クラス自体は、例外を通知するためのクラスでcatchで分岐させるために使うという理解でよいです。
他にも例外に詳細情報を詰めるとかもろもろありますが・・・

戻り値で処理の成功失敗を判定すると、コードに本来やりたいこと以外の判定処理が増えていくので
正常系しか書かずに、想定外（例外）が発生した場合に例外フローに遷移させるために、try～catchがあります。

Design by Contract(DbC：契約による設計)とかでググルとためになる記事がいっぱいでてくると思います。（例外機構への賛否もでてきますが）

---

例外以外にも、プロブラムの文法が何を目的にしてるのか理解できるので、

コーディングを支える技術はオススメです。
今回の場合は、６章 エラー処理のところですね。

書籍の名前が微妙なので周りであまり評判聞かないですが、すごい良書です。

Comments

[AGadget]

ご回答ありがとうございます！

処理失敗時に戻り値ではなく、例外クラスを利用することで、コードが見やすくなったりするメリットが得られるわけですね。おすすめ頂いた書籍のほうも読ませて頂きます。

Answer 2

Javaではなく.NETの処理系についての解説ですが、私が過去に読んだ中ではこの解説が一番わかりやすいと思いました。
.NETの例外処理 Part.1（part4まであります）

基本的な考え方は言語を問わずある程度通用するかと思いますが、違う部分もあります。
特にJavaとの違いについてはコメント欄や以下の別記事で触れられているんで、併せて読めば参考になるんじゃないでしょうか。
.NETとJavaの例外処理の違い

Comments

[AGadget]

ご回答ありがとうございます!

貼って頂いた記事読ませて頂きました。完全には理解できませんでしたが話の輪郭は掴めたかと思います。

記事を読んだ限り、やはりJavaの例外処理は難しいという印象です。.NETの例外処理のほうがシンプルで私は好きですね。後日また、しっかり読ませて頂きます。

Answer 3

例えば、インスタンス化なら「new演算子を使うことでインスタンスが作られて、そのアドレスへの参照が変数に代入して～」といった感じに人に説明できますし、絵にも書くことができますが、例外クラスはまるでイメージできません。

いわゆる「例外を投げる」ということの正体は、java.lang.Exceptionか、それを継承したクラスのインスタンスをthrowsキーワードで投げるということに他なりません。

特に厄介なのがthrows文で「『例外を呼び出し元に返す(呼び出し元で処理する)』ってどういうこと!?　例外を呼び出し元に戻り値として渡しているってこと!?」といった具合に混乱しております。

その理解で大体いいと思います。通常はメソッドなどの結果を呼び出し元に返し、呼び出し元ではその結果を使って処理を進めます。一方で例外が発生した場合は、結果が返せないということを呼び出し元に知らせるということです。

上司・部下で考えるとわかりやすいのではないでしょうか。
「メソッドを呼ぶ」とはつまり、特定の仕事を部下に出すということです。
正常に仕事ができれば結果(報告書など)が得られますが、何らかの理由でできない場合はその旨をその指令を出した人に報告しますよね？その報告を受けた上司はそれに対して何らかの処理をする、という構図は見えますでしょうか。これが「例外を呼び出し元に返す」ということです。

Comments

[gentaro]

上司部下のメタファであれば「鬱病Exception」とか考えるとわかりやすい。（そりゃ結果は返せない…）

[AGadget]

ご回答ありがとうございます！

なるほど、結果が返せない、という報告を呼び出し元に返しているわけですか。いや、その発想は無かったですね。「正常終了なら『0』、異常終了なら『1』を返す」といった考え方しか持っておりませんでしたので。

分かりやすいご回答ありがとうございました。

Answer 4

例外は, 例外です. 既存のルートでは無いフローですので, 既存の延長で考えてはいけないと思います.

例外を throw すれば即メソッドを抜け, 呼び出し元の catch にフローが移り, 例外クラス(インスタンス)から情報が得られる...が分かれば私には十分です.

Comments

[AGadget]

ご回答ありがとうございます！

例外処理は仕組みも例外的……その発想は無かったです。ご指摘頂いた通り、視野が狭くなっていたかもしれません。多角的に例外処理について考えてみようと思います。

Answer 5

なかなか深い問いですね。。。例外には賛否あるようで、思想もなかなか深い気がします(モダンな言語でも例外がある言語と無い言語があるくらいなので)。
とりあえず、私見を述べますと、

• 例外は「異常を見つけたが、自分の役割では適切な対処がわからない場合に、投げるもの(外側に、呼び出し側に)」
  • 例えば、「LocalFileを読みだせ」と言われたが、そんなファイルが無い場合、どうしたらいいかわからないので、IOExceptionを投げる、みたいな
• 呼び出し側は、自分の役割で対応できる例外は catch して、それ以外はスルーする(なので、自分が対応できる例外かどうかの見分けが簡単になるように、例外は階層的になっているし独自の例外も定義できる)
  • ここで(通常)やってはいけないのは、全ての例外を catchして握りつぶすこと。まあ、それで良いときもありますが。
• 例外の代わりに、Returnで例外情報をリレーすることも可能だが、それが面倒で可読性が落ちるので例外がある意義がある

くらいの理解です(まあ、基本中の基本ですが)。

真面目なアプリケーションだと、しっかりと例外を設計して、どのレイヤーで処理するかが大事な場合があります。
Batch処理とかちょっと書いたインスタントなコードだと、例外は全て外側に投げてしまって、プロセス全体をエラーで終了した方がいい場合もあります。
全体的にはわりと何もせず外に投げてしまうのが、良い場合が多い気がしますね。

Comments

[AGadget]

ご回答ありがとうございます！

真面目なアプリケーションですと例外が発生したとき、どの層で例外を処理するか決めることがあるのですね。そういえばOOPは各クラスに責任を適切に配分することが大事であると聞いたような、そうでもないような……。

各層にどれだけ責任を持たせるかを意識する、現在の層で対応できないなら外側の層に投げていくという考え方が例外処理を理解するうえで、とても参考になりました！