【2026年8月最新】Javaのtry-catch文｜throwとthrowsの使い分けを解説｜非エンジニアはClaude Codeに任せる選択肢も
aikanri-admin
「Javaのコードでthrowとthrows、どっちがどっちだっけ？」「try-catchは知っているけど、いつthrowsを付ければいいのか分からない」——Java学習者が必ずと言っていいほどつまずくポイントです。
throwとthrowsは綴りが1文字違うだけなのに、役割はまったく異なります。throwは「今ここで例外を発生させる」命令であるのに対し、throwsは「この処理は例外が起きるかもしれないので、呼び出し元で対処してください」という宣言です。この違いを理解しないまま書いていると、コンパイルエラーが取れない、想定通りにエラーが処理されないといったトラブルにつながります。
この記事では、Javaの例外処理（try-catch文）の基本から、throwとthrowsの使い分け、checked例外・unchecked例外の違い、try-catch-finallyの正しい書き方、複数のcatchを並べるときの順序ルールまでを整理します。さらに後半では、弊社（株式会社GENAI）がAIエージェントにコードを書かせる際、例外処理の品質をどう見ているかという実運用データと、「そもそもコードを書かずにClaude Codeに任せる」という非エンジニア経営者向けの選択肢も紹介します。
AI鬼管理山崎
代表菅澤
01 EXCEPTION BASICS 例外処理（try-catch）とは何か なぜJavaにはエラーを「捕まえる」仕組みがあるのか
プログラムを実行していると、「ファイルが見つからない」「0で割り算をしようとした」「配列の範囲外を参照した」といった、想定外の事態が発生することがあります。Javaでは、こうした異常事態を例外（Exception）というオブジェクトとして表現し、プログラムがいきなり異常終了するのではなく、適切に対処できる仕組みを用意しています。それがtry-catch文です。
📚 用語解説
例外（Exception）：プログラムの実行中に発生する「想定外の事態」を表すJavaのオブジェクト。ファイルが存在しない、数値の割り算でゼロ除算が起きた、配列の範囲外にアクセスしたなど、通常の処理フローでは対処しきれないエラーが起きたときに「例外が発生（スロー）した」という言い方をします。
1-1. try-catchの基本構文
もっとも基本的な形は、tryブロックの中に「例外が起きるかもしれない処理」を書き、catchブロックの中に「例外が起きたときの対処」を書く、というシンプルな構造です。tryブロック内で例外が発生すると、その時点でtryブロックの残りの処理はスキップされ、対応するcatchブロックに処理が移ります。
例えば、ファイルを読み込む処理をtryで囲み、ファイルが見つからなかった場合に「ファイルが見つかりません」というメッセージを表示する処理をcatchに書いておけば、プログラムが異常終了することなく、ユーザーに分かりやすいメッセージを返して処理を続行できます。
try：例外が起きるかもしれない処理を書くブロックcatch：例外が発生したときに実行される処理を書くブロックfinally：例外の有無にかかわらず必ず実行されるブロック（後述）tryブロックの残りはスキップされ、即座にcatchに移る例外処理を書かずに例外が発生すると、プログラムはその場で異常終了し、コンソールにスタックトレースと呼ばれるエラーの発生経路が表示されます。業務システムであれば、ユーザーの目の前で「原因不明のエラー画面」が出てしまう状態です。try-catchは、この異常終了を防ぎ、想定内の形でエラーに対処するための仕組みだと理解すると腹落ちしやすくなります。
📚 用語解説
スタックトレース（Stack Trace）：例外が発生した際に、その例外がどのメソッドのどの行から発生し、どういう順番で呼び出されてきたかを示す情報。エラーメッセージと合わせて出力されるため、開発者が原因箇所を特定する際の重要な手がかりになります。Claude Codeのようなエージェントにエラーを調査してもらう際も、このスタックトレースをそのまま貼って渡すと解決が早まります。
1-2. 例外処理がないと何が困るのか
「エラーが起きたらプログラムが止まればいいのでは」と思うかもしれませんが、業務システムの多くは止まってはいけない処理です。例えば、100件のデータを1件ずつ処理していく途中、97件目でエラーが起きたときに、そこで処理全体が異常終了してしまうと、残り3件だけでなく、それまで処理した96件の結果も失われかねません。try-catchで例外を捕まえ、「エラーが起きた行はログに記録してスキップし、残りの処理を続行する」といった設計にしておくことで、システム全体の安定性が大きく向上します。
代表菅澤
02 THE THROW KEYWORD throwとは？意図的に例外を発生させる命令 「ここでエラーにする」と自分でスイッチを入れる仕組み
throwは、その場で例外を意図的に発生させるためのキーワードです。throw new IllegalArgumentException("値が不正です");のように書くと、その行が実行された瞬間に例外が発生し、以降の処理は中断されて、対応するcatchブロック（または呼び出し元）に処理が移ります。
📚 用語解説
throw：その場で例外オブジェクトを発生（スロー）させるJavaのキーワード。throw new 例外クラス名("メッセージ")という書き方で使う。Javaが自動的に発生させる例外（配列の範囲外アクセスなど）とは異なり、開発者が意図的に「ここはエラーにすべきだ」と判断した場面で使う点が特徴です。
2-1. throwを使う典型的な場面
throwがよく使われるのは、Javaの言語仕様としてはエラーにならないが、業務のルール上は不正な値であるケースです。例えば「年齢に-5という値が渡された」というのは、int型としては正しく処理できてしまいますが、業務的には明らかにおかしい値です。こうした「文法上は正しいが、意味的には誤り」というケースを検出し、その場でthrowで例外を発生させることで、不正な値が後続の処理に流れ込むのを防ぎます。
throw文が実行されると、その時点でメソッドの実行は中断されます。throwの直後に別の処理を書いても、その行は絶対に実行されません。「throwを書いたのに後続の処理が動いてしまう」という相談は、実際には別の分岐で例外が発生していないケースがほとんどです。
AI鬼管理山崎
throwは「ここでエラーとして扱ってください」という宣言ではなく実行です。条件分岐の中に置いて、条件を満たしたその瞬間に処理を止める、というイメージで覚えると使い分けの感覚がつかみやすくなります。03 THE THROWS KEYWORD throwsとは？呼び出し元に処理を委譲する宣言 「このメソッドは例外が起きるかもしれません」という予告
一方のthrowsは、メソッドの宣言部分に書くキーワードで、「このメソッドを実行すると、こういう種類の例外が発生する可能性があります」ということを呼び出し元に伝える役割を持ちます。public void readFile() throws IOException { ... }のように、メソッド名の後ろに書きます。
📚 用語解説
throws：メソッドの宣言（シグネチャ）に付与し、「このメソッドの内部で、指定した種類の例外が発生する可能性がある」ことを呼び出し元に知らせるキーワード。throwsが付いたメソッドを呼び出す側は、その例外に対してtry-catchで対処するか、自分自身も同じ例外をthrowsで宣言して、さらに上位の呼び出し元に処理を委ねる必要があります。
3-1. throwsは「自分では対処しない」という意思表示
throwsを使う最大のポイントは、「このメソッド自身は例外への対処を行わず、呼び出し元に委ねる」という設計判断です。例えばファイルを読み込むメソッドの中で例外が起きたとき、「ファイルが見つからなかったらどうするか」の判断は、そのメソッドを呼び出す側（画面表示をする側や、業務ロジック側）に委ねた方が適切なケースがあります。そうした場合に、メソッド側は自分でcatchせず、throwsで例外の可能性だけを宣言しておく、という設計になります。
3-2. throwsを使う場合の呼び出し元の義務
throwsが付与されたメソッドを呼び出すコードは、Javaのコンパイラによって「例外への対処」を強制されます。具体的には、呼び出し元でtry-catchを使ってその場で処理するか、呼び出し元のメソッド自身も同じ例外をthrowsで宣言して、さらに上のメソッドに処理を委ねるかのどちらかを選ぶ必要があります。この仕組みにより、「例外が発生する可能性があるのに、誰もそれに対処していない」という状態をコンパイル時点で検出できるのがJavaの大きな特徴です。
throwsで
例外の可能性を宣言
try-catchで
対処 or
throwsで
委譲を続ける
必ず対処
コンパイラが
チェックする
同じメソッドの中で、業務ルール違反をthrowで意図的に発生させつつ、そのメソッド自体はthrowsで「この例外が起きる可能性があります」と宣言する、という組み合わせもよく使われます。throwは「実行する動作」、throwsは「宣言する情報」という役割の違いを押さえておくと混乱しません。
代表菅澤
04 THROW VS THROWS throwとthrowsの使い分け一覧 混同しがちな2つのキーワードを一枚の表で整理する
ここまでの内容を、比較表として一枚にまとめます。試験対策やコードレビューの際にも、この表を思い出せれば迷うことはなくなります。
| 観点 | throw | throws |
|---|---|---|
| 書く場所 | メソッドの中（処理の一部として） | メソッドの宣言部分（メソッド名の直後） |
| 役割 | 例外をその場で発生させる「実行」 | 例外が起きる可能性を伝える「宣言」 |
| 対象 | 例外オブジェクトを1つ指定 | 例外クラスを複数、カンマ区切りで指定できる |
| 書き方の例 | throw new IOException("失敗"); | void read() throws IOException |
| 実行への影響 | 実行された瞬間に処理が中断される | それ自体では処理は中断されない（宣言のみ） |
4-1. 一言で言い換えると
迷ったときは、throwは「投げる」という動作そのもの、throwsは「投げる可能性がある」という予告、と言い換えると区別しやすくなります。英語の文法に例えると、throwが動詞（動作）、throwsは「throwする可能性のあるメソッドです」という形容詞的な修飾、というイメージに近い関係です。
📚 用語解説
checked例外とunchecked例外：Javaの例外は大きく2種類に分かれます。checked例外（IOExceptionなど）は、throwsでの宣言かtry-catchでの対処をコンパイラが強制するタイプ。unchecked例外（RuntimeException系、NullPointerExceptionやArrayIndexOutOfBoundsExceptionなど）は、宣言や対処が強制されず、プログラムのバグに起因することが多いタイプです。throwsの記述が必須になるのは主にchecked例外を扱うときです。
unchecked例外（RuntimeExceptionのサブクラス）は、throwsで宣言しなくてもコンパイルエラーになりません。そのため「コンパイルが通ったから例外処理は万全」とは限らない点に注意が必要です。unchecked例外は、実行時に想定外の入力やバグによって発生することが多く、根本的な対策はthrows宣言よりも、入力値の事前チェックやテストの充実になります。
4-2. 複数の例外を扱う場合の書き方
throwsは、カンマ区切りで複数の例外クラスをまとめて宣言できます（throws IOException, SQLExceptionのように）。また、catch側もJava 7以降はcatch (IOException | SQLException e)というマルチキャッチの構文で、複数の例外を1つのcatchブロックでまとめて処理できます。処理内容が同じであれば、catchブロックを何個も並べるより、マルチキャッチでまとめた方がコードがすっきりします。
📚 用語解説
マルチキャッチ（Java 7以降）：catch (例外A | 例外B e)のように、パイプ（|）で複数の例外クラスを1つのcatchブロックにまとめて記述できる構文。複数の例外に対して同じ対処をしたい場合に、重複したcatchブロックを書かずに済むため、コードの見通しが良くなります。
05 TRY-CATCH-FINALLY try-catch-finally文の正しい書き方 「必ず実行される」finallyの役割と、複数catchの順序ルール
try-catchに加えてよく使われるのがfinallyブロックです。finallyブロックの中に書いた処理は、例外が発生したかどうかにかかわらず、必ず実行されます。ファイルやデータベース接続のように「使い終わったら必ず閉じる必要があるリソース」の後始末を書く場所として使われます。
📚 用語解説
finally：try-catchの後に続けて書くブロックで、例外の有無や、catch内でreturnした場合でも必ず実行される処理を書く場所。ファイルのクローズ処理やデータベース接続の解放など、「後始末」を確実に行いたい処理に使われます。
5-1. 複数catchを並べるときの順序ルール
1つのtryブロックに対して、複数のcatchブロックを並べて、例外の種類ごとに異なる処理を書くこともできます。この際に注意すべきなのがcatchの順序です。Javaの例外クラスには継承関係があり、親クラス（より広い範囲をカバーする例外）を先に書いてしまうと、子クラス（より詳細な例外）のcatchが実行されず、コンパイルエラーになります。必ず詳細な例外から先に、広い例外を後に書く必要があります。
例えばException（すべての例外の親にあたるクラス）を最初のcatchに書き、その後にIOExceptionのcatchを書くと、「IOExceptionのcatchには絶対に到達しない」とコンパイラに判定され、エラーになります。catchは常に範囲が狭いものから広いものへという順序で並べるのが鉄則です。
5-2. try-with-resourcesという発展形
Java 7以降では、finallyでリソースを閉じる処理を自分で書かなくても、try (リソースの初期化) { ... }という書き方（try-with-resources）を使うと、tryブロックを抜けるタイミングでリソースが自動的にクローズされます。ファイル操作やDB接続など、クローズ処理が必要なリソースを扱う場合は、finallyで手動クローズするより、こちらを使う方が書き忘れを防げます。
finallyブロックの中でreturn文を書くと、try/catch側のreturnやthrowの結果が上書きされてしまい、意図しない動作の原因になります。finallyは「後始末」に徹し、returnやthrowのような処理フローを変える文は書かないのが安全な設計です。
AI鬼管理山崎
06 COMMON PITFALLS 実務でよくある例外処理のつまずきポイント 「catchして握りつぶす」など、初心者が陥りやすい落とし穴
文法自体を理解していても、実際の業務コードでは「動くけれど良くない書き方」に陥りがちです。この章では、現場でよく見かける4つのつまずきポイントを整理します。
6-1. catchブロックを空にして「握りつぶす」
もっとも避けるべきなのが、catch (Exception e) {}のように、catchブロックの中身を空にしてしまう書き方です。これは「例外が発生したことをまるっきり無視する」という意味になり、システムのどこかで問題が起きているにもかかわらず、誰にも気づかれないまま処理が続いてしまいます。
最低限、catchブロックの中ではe.printStackTrace()やログ出力ライブラリを使って、何が起きたのかを記録しておくべきです。「エラーが起きても画面上は正常に見える」という状態は、後になって原因不明の不具合として発覚し、調査に膨大な時間がかかる典型的な事故パターンです。
6-2. 何でもExceptionでcatchしてしまう
個別の例外クラス（IOExceptionやNumberFormatExceptionなど）ではなく、すべての例外の親クラスであるExceptionで丸ごとcatchしてしまうと、本来は種類ごとに異なる対処をすべき問題を、一律の処理でまとめて扱うことになります。開発初期の動作確認では便利ですが、本番運用のコードとしては、発生しうる例外の種類を特定し、それぞれに適した対処を書くのが望ましい設計です。
6-3. 例外メッセージが具体性に欠ける
throwで例外を発生させる際、メッセージを「エラーです」のように曖昧にしてしまうと、後で調査する人（自分自身も含む）が原因を特定するのに時間がかかります。「どの値が」「なぜ」不正だったのかを具体的に書いておくことで、スタックトレースを見ただけで原因の見当がつくようになります。
6-4. 例外処理のテストを書いていない
正常系（うまくいくケース）のテストだけでなく、「わざと不正な値を渡して例外が正しく発生するか」という異常系のテストまで書いておくことで、例外処理のロジックが本当に意図通り動くかを検証できます。異常系のテストが手薄なプロジェクトほど、本番環境で予期しないエラーが表面化しやすい傾向があります。
代表菅澤
07 GENAI CASE DATA 【独自データ】GENAI社内でのAIコード品質チェックの実態 例外処理の設計を、非エンジニアの経営者がどう見ているか
ここからは、弊社（株式会社GENAI）がClaude Codeなどのエージェントにコードを書かせる際、例外処理の品質をどのようにチェックしているかを紹介します。弊社ではClaude Max 20xプラン（月額$200・約30,000円）を全社契約し、経営・営業・広告・開発・経理・秘書業務までClaude Codeを絡めて運用しています。
| 項目 | 内容 |
|---|---|
| 契約プラン | Claude Max 20x（月額$200 / 約30,000円） |
| 利用開始 | 2025年後半〜 |
| 例外処理が関わる業務 | 社内ツール開発、LP・フォーム処理、データ集計スクリプトの書き捨て |
| 主な利用モデル | Sonnet系（日常のコード生成）／Opus系（複雑な設計判断が必要な場面） |
自社で使う小さなツールやスクリプトの多くをClaude Codeに書かせている弊社では、「AIが書いたコードの例外処理をどこまで信頼していいのか」という疑問が、開発を任せ始めた当初から常につきまとっていました。以下は、実際に運用を重ねる中で見えてきた傾向です。
| チェック観点 | 傾向 | 対応方針 |
|---|---|---|
| 空のcatchブロックの有無 | 明示的に指示しないと発生することがある | 「エラーはログに残して」と一言添える運用に変更 |
| Exceptionでの一括catch | 簡易スクリプトでは起きやすい | 本番運用ツールでは種類ごとの対処を明示的に依頼 |
| エラーメッセージの具体性 | 指示次第で改善される | 「原因が分かるメッセージにして」と依頼文に含める |
上記は弊社の運用における肌感ベースの傾向であり、依頼の仕方やプロジェクトの規模によって結果は変動します。「AIにコードを書かせるときに、経営者としてどこを見ておくべきか」の参考情報としてご覧ください。
7-1. 「丸投げ」ではなく「観点を伝える」運用へ
弊社での実感として、Claude Codeに「エラー処理も書いておいて」とだけ伝えるより、「エラーは握りつぶさずログに残す」「想定外の値が来たら具体的な理由と一緒にエラーを返す」といった観点を具体的に伝えた方が、圧倒的に品質の高いコードが返ってくる傾向があります。これはこの記事で解説した「空のcatch」「Exceptionでの一括catch」「曖昧なメッセージ」という3つの落とし穴を、依頼側があらかじめ言語化して伝えているかどうかの差だと捉えています。
つまり、非エンジニアの経営者であっても、この記事で紹介したような例外処理の基本的な考え方（何を避けるべきか）を知っておくだけで、AIに出す指示の質が変わり、結果としてコードの品質も変わるというのが弊社の運用から得られた気づきです。
AI鬼管理山崎
08 OVERCOMING BARRIERS 【独自】非エンジニアがJavaの例外処理を理解するときの3つの壁 コードを書かなくても、判断できる状態になるための現実的なルート
ここまで読んで「用語は分かったけれど、自分でコードを書くのは大変そう」と感じた方も多いと思います。弊社の導入支援でも、この種の技術解説を読んで理解はできても、実際にコーディングまで到達できずに止まってしまうケースを数多く見てきました。ここでは、非エンジニアの経営者・管理職がJavaの例外処理のような技術トピックに向き合うときに越える3つの壁を整理します。
8-1. 【壁1】用語の海に溺れる
最初の壁は、throw・throws・checked例外・unchecked例外・マルチキャッチ……といった専門用語の量そのものです。1つずつは理解できても、まとめて出てくると混乱してしまうという声をよく聞きます。
経営者・管理職の立場であれば、この記事のすべての用語を暗記する必要はありません。「throwは実行、throwsは宣言」「空のcatchは危険」という2〜3個の要点だけ押さえておけば、開発チームやAIとのコミュニケーションで困ることはほとんどありません。
8-2. 【壁2】実際に手を動かして試せない
2つ目の壁は、Java開発環境（JDKやIDE）を用意して、実際にコードを書いて動かしてみる実践の場が用意できないことです。読むだけでは理解が深まらないと分かっていても、環境構築のハードルで止まってしまいます。
8-3. 【壁3】自分のコードが正しいか判断できない
3つ目の壁は、仮に自分でコードを書けたとしても、あるいはAIが書いたコードを渡されたとしても、それが正しい設計なのかを判断する自信が持てないという点です。これはエンジニア経験がない限り、ある程度は仕方のないことです。
ざっくり理解
throw/throwsの
役割の違いだけ
3つだけ覚える
空catch/一括catch/
曖昧メッセージ
伝えて依頼
「エラーは握り
つぶさないで」等
違和感だけ確認
完璧なレビューは
目指さない
代表菅澤
09 DECISION GUIDE 自分で学ぶか、Claude Codeに任せるかの判断基準 「学ぶ価値がある場面」と「任せた方が早い場面」を切り分ける
最後に、この記事で解説したJavaの例外処理を「自分でコーディングまで習得する」べきか、「Claude CodeのようなAIエージェントに任せる」べきかの判断軸を整理します。どちらが絶対的に正しいというものではなく、立場と目的によって最適解が変わります。
| 状況 | おすすめ | 理由 |
|---|---|---|
| エンジニア職で、Javaでの開発を仕事にしている | 自分で学ぶ | 例外設計を自分の判断でできることが長期的な資産になる |
| 非エンジニアで、社内ツールをたまに作ってもらう立場 | Claude Codeに任せる＋要点だけ理解 | 実装の詳細より、依頼と判断ができれば十分 |
| 経営者・管理職で、複数の開発案件を並行して見ている | Claude Codeに任せる | 自分の時間は判断・意思決定に使う方が投資対効率が高い |
| プログラミング自体に興味があり、体系的に学びたい | 自分で学ぶ | 例外処理はJavaの言語仕様の中核で、実務との接続も強い教材 |
9-1. 「動くコードを書かせる」ならAIで十分なケースが多い
社内で使う簡易なツールやスクリプト単位であれば、コードの書き方を1から調べながら自分で実装するより、Claude Codeに要件と一緒に「エラーは握りつぶさず、原因が分かるメッセージにして」という観点を伝えて依頼した方が、実務では圧倒的に早く、かつ一定水準以上の品質にたどり着けます。この記事で紹介した用語や落とし穴は、その依頼を的確に行うための語彙として機能します。
📚 用語解説
AIエージェント：人間が細かく手順を指示しなくても、目的を伝えるだけで自ら計画を立てて複数の作業ステップを実行するAI。Claude Codeは、コードの生成・実行・エラー内容の確認・修正までを一連の流れとして自律的にこなせるため、Javaの文法や例外処理の詳細を人間側が全て把握していなくても、要件と品質基準さえ伝えられれば実装まで任せられるのが特徴です。
9-2. 用語を知っていると、AIとの会話の解像度が上がる
一方で、この記事で紹介したthrowとthrowsの違いや、空のcatchが危険であるといった知識を持っておくと、Claude Codeが出してきたコードに対して「この設計で本当に合っているか」を自分の言葉で確認できるようになります。すべてを自分でコーディングする必要はなくても、仕組みの要点を知っておくことには実務的な価値がある、というのがこの記事全体を通しての結論です。
「基本の判断基準は理解しておき、実際のコーディングはAIに任せる」という併用スタイルが、非エンジニアの経営者・管理職にとって最も無理のない着地点です。今回学んだ「例外を握りつぶさない」「メッセージは具体的に」という知識は、Claude Codeに指示を出す際の会話の解像度を上げる材料としても役立ちます。
10 CONCLUSION まとめ ── throw/throwsは「実行」と「宣言」の違い 覚えておくべき要点と、判断の軸を最後に振り返る
この記事では、Javaのtry-catch文の基本から、throwとthrowsの使い分け、checked/unchecked例外の違い、try-catch-finallyの正しい書き方、実務で起きやすいつまずきポイント、そして弊社GENAIのAIコード品質チェックの実運用データと、非エンジニア向けの判断基準までを整理しました。最後にポイントを振り返ります。
throwとthrowsの違いは、Java学習者が最初につまずきやすいポイントの一つですが、「実行か、宣言か」という軸さえ押さえれば迷うことはなくなります。エンジニアであれば、この記事の内容をベースに例外設計の実践力を伸ばしていけますし、非エンジニアの経営者・管理職であれば、要点だけを理解したうえで、実際のコーディングはClaude CodeのようなAIエージェントに任せてしまうのが現実的な選択です。
代表菅澤
社内ツールの開発・品質管理、Claude Codeでどこまで任せられるか一緒に整理します
例外処理の設計のような「地味だけれど品質を左右する部分」は、依頼の仕方次第でAIの出力が大きく変わります。
弊社の実運用ノウハウをベースに、貴社の開発業務にどこまで適用できるかを個別にご相談いただけます。
AI鬼管理山崎
ここから先の進め方は、大きく2つあります。
自社で回せるようになりたい方は、AI鬼管理でClaude Code／Codexの使い方から業務設計・社内定着まで伴走を受けながら、社内に仕組みを作る道があります。
覚えるより任せたい方は、AIBPO by AI鬼管理でこの記事のような定型業務を丸ごと預ける道があります。総額はいまの業務コストの50%が目安、月額基本料は0円です。
どちらが合うかは、業務量と社内体制次第です。無料相談・無料適合診断で、貴社の場合はどちらが向くかからご相談いただけます。
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
よくある質問
Q. throwとthrowsの違いを一言で説明するとどうなりますか？
A. throwは「その場で例外を発生させる実行文」で、メソッドの処理の中に書きます。throwsは「このメソッドは例外が起きる可能性がある」ことを呼び出し元に伝える宣言で、メソッド名の直後に書きます。実行するthrow、宣言するthrowsという役割の違いで覚えると混同しません。
Q. throwsを付け忘れるとどうなりますか？
A. checked例外（IOExceptionなど）を発生させる可能性がある処理に対してthrowsの宣言もtry-catchでの対処も書いていない場合、コンパイルエラーになります。Javaはこの仕組みによって「例外の可能性があるのに誰も対処していない」という状態をコンパイル時点で検出できるようになっています。
Q. checked例外とunchecked例外はどう見分ければいいですか？
A. Exceptionのサブクラス（IOExceptionのように間接的に継承している場合も含む）のうち、RuntimeExceptionを継承していないものがchecked例外で、throwsまたはtry-catchでの対処が必須です。RuntimeExceptionを継承している例外（NullPointerExceptionなど）はunchecked例外で、対処は必須ではありません。「直接継承かどうか」ではなく「RuntimeExceptionの系統かどうか」で判断するのが正確です。
Q. 複数のcatchブロックを書くとき、順番に決まりはありますか？
A. あります。範囲が狭い（詳細な）例外クラスを先に、範囲が広い例外クラスを後に書く必要があります。広い例外クラスを先に書いてしまうと、後に続く詳細な例外のcatchには絶対に到達しないと判定され、コンパイルエラーになります。
Q. catchブロックを空にするのはなぜダメなのですか？
A. 例外が発生した事実そのものが記録されず、システムのどこかで問題が起きていても誰も気づけない状態になるためです。最低限、ログに例外の内容を出力しておくことで、後から原因を追跡できるようにしておくのが基本のマナーとされています。
Q. finallyブロックの中でreturnを書いてもいいですか？
A. 文法上は書けますが、避けるべきとされています。finally内のreturnは、try側やcatch側で行われたreturnやthrowの結果を上書きしてしまい、意図しない動作の原因になります。finallyはリソースの解放など「後始末」に専念させるのが安全な設計です。
Q. Javaが書けなくても、例外処理の品質をチェックする方法はありますか？
A. あります。この記事で紹介した「catchブロックが空になっていないか」「Exceptionで一括catchしていないか」「エラーメッセージが具体的か」という3つの観点だけ知っていれば、Claude CodeのようなAIが書いたコードに対して的確なレビュー依頼や指摘ができます。細かい文法を暗記する必要はありません。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理／AIBPO by AI鬼管理へのお問い合わせ
この記事を読んで気になった方へ。
専門スタッフが、御社に最適な
業務自動化・業務代行プランを無料でご提案します。
- AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
- Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
- 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
- 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
- メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
- 明治大学政治経済学部卒
