Javaエンジニアへの第一歩！エラーに負けない例外処理の基本と実践

2026年3月19日 最終更新日時 : 2026年3月19日 山崎講師山崎講師

こんにちは。ゆうせいです。

これから皆さんと一緒に、Javaのプログラミングにおいて避けては通れない「例外処理」の世界を冒険していきましょう。

せっかく書いたプログラムが急に止まってしまったら悲しいですよね？

でも、大丈夫です。例外処理をマスターすれば、予期せぬトラブルが起きても優雅に対応できるようになります。

みなさんは、プログラムが「動かなくなること」を恐れていませんか。

実は、正しくエラーを出すことこそが、一流のエンジニアへの近道なのです！

今回の記事では、Javaの例外処理（Exception）について、基礎から実践的な設計思想までを網羅した研修教材を作成しました。

本講座の構成

本研修は全7章で構成されています。

  1. 第1章：なぜ例外が必要なのか？（エラー通知の歴史と例外の正体）
  2. 第2章：例外の家系図（Throwableから始まるクラス階層）
  3. 第3章：二つの例外（CheckedとUncheckedの使い分け）
  4. 第4章：try-catch-finallyの三銃士（実行順序とリソース管理）
  5. 第5章：例外を投げる技術（throwとthrowsの違い）
  6. 第6章：エラーの足跡を辿る（スタックトレースと例外伝播）
  7. 第7章：実践！カスタム例外とアンチパターン（例外を握り潰さないために）

第1章：なぜ例外が必要なのか？（エラー通知の歴史と例外の正体）

概要

この章では、プログラムにおける「エラー」の捉え方を学びます。

昔ながらの手法である「戻り値によるエラー判定」と、現代的な「例外処理」の違いを理解し、なぜJavaがこの仕組みを採用しているのかを紐解いていきましょう。

昔のエラー通知とJavaの例外

Javaが登場する前の古い言語では、メソッドが失敗したことを「特定の数値（エラーコード）」を返して伝えていました。

例えば、成功なら0、ファイルが見つからなければ-1、メモリ不足なら-2、といった具合です。

しかし、この方法には大きな弱点がありました。

呼び出し側が毎回「もし戻り値が-1だったら……」とチェックをしなければならず、本来の目的である処理（ビジネスロジック）がエラーチェックの山に埋もれてしまうのです。

Javaの例外処理は、この「正常な処理」と「異常な処理」をパカッと切り離すために生まれました。

コード抜粋：エラーコード vs 例外処理

まずは、古いスタイルのイメージを見てみましょう。

int result = fileReader.open("data.txt");
if (result == -1) {
    System.out.println("ファイルがありません");
} else if (result == -2) {
    System.out.println("権限がありません");
} else {
    // ここでようやく本題の処理
}

次に、Javaの例外処理を使ったコードです。

try {
    fileReader.open("data.txt");
    // ここに本題の処理だけを書ける！
} catch (FileNotFoundException e) {
    System.out.println("ファイルが見つからない時の専用処理");
} catch (SecurityException e) {
    System.out.println("権限がない時の専用処理");
}

逐次解説

1行目：tryという魔法の箱を用意します。

2行目：この箱の中には「失敗するかもしれないけれど、本来やりたいこと」を記述します。

3行目：ここで正常系の処理が続きます。エラーチェックを挟む必要はありません。

4行目：catchが登場します。これは「もしFileNotFoundExceptionというトラブルが起きたら捕まえる」という網のようなものです。

5行目：トラブルが起きた時だけの専用の処理（ログ出力など）を書きます。

図解イメージ：バケツリレーとホイッスル

プログラムの実行をバケツリレーに例えてみましょう。

正常な時は、次々とバケツ（データ）を隣の人に渡していきます。

ところが、途中でバケツを落として壊してしまった人がいたらどうなるでしょうか。

エラーコード方式では、壊れたバケツに「壊れた」というメモを貼って、そのまま隣の人に渡し続けます。受け取った人は毎回メモを確認しなければなりません。

一方、例外処理方式は「ホイッスル」です。

バケツが壊れた瞬間、その人が「ピーッ！」と笛を吹きます。

すると、通常のバケツリレーは即座に中断され、あらかじめ待機していた「救護班（catchブロック）」が駆けつけるのです。

これなら、リレーの走者たちはバケツを運ぶことだけに集中できますよね。

よくある誤解

よくある間違いは、「例外はプログラムのバグを見つけるためのものだ」という思い込みです。

もちろんバグを見つける助けにもなりますが、本来の役割は「想定外の事態（ネットワーク断線やファイルの欠落など）が起きても、システム全体を安全に動かし続けること」にあります。

例外は「敵」ではなく、安全装置なのです。

実務での重要性

現場のコードでは、正常なケースよりも「異常なケース」の方が圧倒的に多いものです。

例外処理を適切に書かないと、エラーが起きた瞬間にシステムが沈黙し、どこで何が起きたのか全く分からなくなります。

「正常に動くこと」と同じくらい、「異常時に正しく騒ぐこと」がプロには求められます！

演習問題

  1. エラーコード方式と比較して、Javaの例外処理（try-catch）を使う最大のメリットは何でしょうか？
  2. tryブロックの中で例外が発生したとき、その後のtryブロック内の処理はどうなりますか？

第1章、お疲れ様でした！

まずは「例外は、本来の処理をスッキリさせるための安全装置」というイメージが持てれば完璧です。

さて、次は「どんな種類の例外があるのか？」という、例外の家族構成について見ていきましょう。

第2章：例外の家系図（Throwableから始まるクラス階層）

概要

Javaの例外処理に登場するクラスは、すべて java.lang.Throwable というクラスの子孫です。 この章では、ピラミッド型の階層構造を理解し、「システムが壊れた時のエラー」と「プログラムで対処すべきエラー」の境界線を学びます。

コード抜粋：型によるキャッチの使い分け

try {
    // 何らかの処理
} catch (RuntimeException e) {
    // 実行時のうっかりミスを捕まえる
    System.out.println("プログラムの論理ミスです");
} catch (Exception e) {
    // それ以外の「想定内のトラブル」を捕まえる
    System.out.println("外部要因のトラブルです");
} catch (Throwable t) {
    // 最終手段：あらゆる深刻な事態を含めて捕まえる（通常は非推奨）
    System.out.println("何かが致命的に起きました");
}

逐次解説

1行目：処理を開始します。 4行目：RuntimeExceptionは「実行時例外」と呼ばれ、配列のインデックス範囲外アクセスなどのミスを指します。 7行目：Exceptionはより広い範囲を指します。RuntimeExceptionもこの中に含まれます。 10行目：Throwableは全ての頂点です。後述する「Error」もここに含まれます。

図解イメージ：ピラミッド型の組織図

例外の階層は、会社の役職のようなピラミッド構造になっています。

  1. 頂点：Throwable（全ての「投げられるもの」の総称）
  2. 左腕：Error（エラー）
  3. 右腕：Exception（例外）
  4. Exceptionの子供：RuntimeException（実行時例外）

これを現実で例えるとこうなります。

  • Errorは「会社が倒産した（プログラムを動かしている環境が壊れた）」状態です。社員（プログラマ）が頑張ってもどうにもなりません。
  • Exceptionは「取引先が遅刻した（ファイルが開けない）」状態です。これは「待つ」などの対策が立てられます。
  • RuntimeExceptionは「自分が寝坊した（コードの書き間違い）」状態です。これは事前に気をつければ防げますよね。

よくある誤解

「何でもかんでも Exception e でキャッチすれば楽じゃない？」と思うかもしれません。 しかし、これは「誰か助けて！」と叫ぶべき時に「何かが起きた」とだけ報告するようなものです。 原因が「ファイル不足」なのか「ネットワーク切れ」なのか区別がつかないと、適切な救急処置（復旧処理）ができなくなってしまいます。可能な限り、具体的なクラス名で捕まえるのがマナーです。

実務での重要性

実務では、特に Error クラスを catch することはほとんどありません。 メモリ不足（OutOfMemoryError）などの Error が起きたとき、プログラムはすでに虫の息だからです。 私たちが救うべきは Exception 以下の子供たちであることを意識しましょう。

演習問題

  1. Exception クラスと Error クラスの決定的な違いを一言で説明してください。
  2. 自分で新しく「独自の例外クラス」を作りたいとき、通常はどのクラスを継承（親に指定）すべきでしょうか？

いかがでしょうか。Javaの世界にもしっかりとした「血縁関係」があることが分かると、エラーメッセージの見え方が変わってきませんか？

次は、現場で最も議論になる「二つの例外（CheckedとUnchecked）」について詳しくお話ししますね。ここが理解できると、設計ができるエンジニアに一歩近づきます！

第2章の家系図、スッキリ整理できましたね！ 続いて第3章では、Javaエンジニアが設計時に最も頭を悩ませ、かつ最も重要な「二つの例外の使い分け」について解説します。

第3章：二つの例外（CheckedとUncheckedの使い分け）

概要

Javaの例外には、コンパイラが「これ、対策してないとダメだよ！」と厳しくチェックしてくれる「Checked例外（検査例外）」と、実行してみるまで分からない「Unchecked例外（非検査例外）」の2種類があります。 この章では、なぜJavaにこの2つの区分があるのか、その設計意図を学びます。

コード抜粋：コンパイラの厳しさが違う！

// 1. Checked例外（検査例外）の例
public void readFile() {
    // 下の行はコンパイルエラーになります！
    // 対策（try-catchなど）を書かないと、プログラムがビルドすらできません。
    FileReader fr = new FileReader("memo.txt"); 
}

// 2. Unchecked例外（非検査例外）の例
public void calculate() {
    // これはコンパイルが通ってしまいます。
    // 実行した瞬間に「0で割れないよ！」と怒られます。
    int result = 10 / 0; 
}

逐次解説

1行目：ファイルを読み込むメソッドです。

4行目：FileReaderは、ファイルがない可能性（FileNotFoundException）があるため、Javaが「絶対に対策を書け」と強制します。これがChecked例外です。

8行目：計算をするメソッドです。

11行目：0での割り算はArithmeticExceptionを発生させますが、Javaはこれを事前に強制チェックしません。これがUnchecked例外です。

図解イメージ：信号機と不意打ち

この違いは、道路の「信号機」と「不意の落とし穴」に例えられます。

  • Checked例外（信号機） 交差点（ファイル操作やネットワーク接続）には信号機があります。赤信号（エラー）になる可能性があることは最初から分かっているので、運転手（プログラマ）はあらかじめ「止まる準備（try-catch）」をしておかなければ、道路（コンパイラ）を通らせてもらえません。
  • Unchecked例外（不意の落とし穴） 平坦な道（普通の計算や変数操作）を歩いているとき、突然穴に落ちるようなものです。これは「歩き方が悪い（プログラミングミス）」のが原因です。道自体に「穴に落ちる準備をしろ」という信号を全部立てていたら、歩きにくくて仕方がありませんよね。

よくある誤解

「Checked例外は面倒だから、全部RuntimeException（Unchecked）にしてしまえばいいのでは？」という意見を耳にすることがあります。 確かにコードは短くなりますが、それは「信号機を全部撤去する」のと同じです。 呼び出し側が「ここでエラーが起きる可能性がある」と気づけなくなり、結果としてシステムが突然クラッシュする危険性が高まってしまいます。

実務での重要性

実務では、以下の基準で使い分けます。

  • Checked例外：ネットワーク遮断など、プログラマが気をつけても防げない外部要因。呼び出し側に「リトライ」などのリカバリを促したい時に使います。
  • Unchecked例外：引数がnullだった、配列のサイズを間違えたなど、プログラマが事前にチェック（if文など）すれば防げるミス。

演習問題

  1. RuntimeExceptionを継承して作った自作例外は、CheckedとUncheckedのどちらになりますか？
  2. 「データベースのパスワードが間違っていて接続できない」という状況は、どちらの例外で設計すべきでしょうか？理由も考えてみましょう。

CheckedとUncheckedの違い、イメージできましたか？ これを知っているだけで、「なぜここにtry-catchを書かされるのか」という理由が分かり、Javaとの対話がスムーズになりますよ！

次は、いよいよ例外処理の具体的な書き方、try-catch-finallyの「実行順序」というパズルについてお話しします。

第2章と第3章で「例外とは何か」という正体が見えてきましたね。 第4章では、いよいよプログラムの中で例外をどう捕まえ、どう後始末するかという具体的な書き方、try-catch-finallyの「実行順序」というパズルを解き明かしましょう。

第4章：try-catch-finallyの三銃士（実行順序とリソース管理）

概要

例外が発生したとき、プログラムの処理は一瞬で飛び火します。 この章では、try、catch、そしてfinallyという3つのブロックが、どのような順番で実行されるのかを正確に理解します。特に、エラーが起きても「絶対に実行される」finallyの重要性を学びましょう。

コード抜粋：実行順序を追いかけよう

public void process() {
    try {
        System.out.println("1: 処理開始");
        int result = 10 / 0; // ここで例外発生！
        System.out.println("2: 成功！"); // 実行されない
    } catch (ArithmeticException e) {
        System.out.println("3: 例外をキャッチしました");
    } finally {
        System.out.println("4: 最後のお片付け");
    }
    System.out.println("5: メソッド終了");
}

逐次解説

1行目：メソッドが始まります。

3行目：tryブロックに入り、「1: 処理開始」が表示されます。

4行目：0で割ろうとしてArithmeticExceptionが投げられます。

5行目：例外が起きた瞬間にtryブロックを脱出するため、この行は無視されます。

6行目：発生した例外の種類が一致するので、catchブロックに入り「3: 例外をキャッチ……」が表示されます。

8行目：finallyブロックに入ります。例外が起きても起きなくても、ここは必ず通ります。

11行目：例外が正しく処理されたので、メソッドの続きが実行されます。

図解イメージ：ジェットコースターの非常出口

プログラミングの実行をジェットコースターに例えてみましょう。

  1. try（コース）：通常の走行ルートです。
  2. catch（非常出口）：コース上でトラブル（例外）が起きたときだけ、ガシャンと切り替わる専用の退避ルートです。
  3. finally（出口の検問所）：コースを無事に完走しても、非常出口を通っても、最後には必ず通らなければならない場所です。

よくある誤解

「finallyなんて書かなくても、catchの下に処理を書けばいいじゃない？」と思うかもしれません。 しかし、もしcatchブロックの中でさらに別の例外が起きたり、returnでメソッドを終了しようとしたりした場合、catchの下の行は実行されません。 でも、finallyだけは、たとえ途中でreturnしても「最後にこれだけはやってから帰るよ！」と割り込んで実行されるのです。

実務での重要性

実務においてfinallyが最も活躍するのは「後片付け」です。 例えば、ファイルを開いたり、データベースに接続したりしたとき、エラーが起きても「接続を閉じる（close）」という処理を忘れると、コンピュータのメモリが食いつぶされてしまいます。 最近では「try-with-resources」というより便利な書き方もありますが、基本はこのfinallyの精神にあります。

演習問題

  1. tryブロックの中で例外が発生せず、無事に終了した場合、finallyブロックは実行されるでしょうか？
  2. catchブロックの中で return; と書いてメソッドを終了しようとした場合、finallyブロックの処理はどうなりますか？

実行順序のルール、整理できましたか？ 「例外が起きても、最後は必ずfinallyで締める」という流れが分かれば、バグに強いコードが書けるようになりますよ！

次は、例外を「捕まえる」のではなく、あえて「投げる」技術、throwとthrowsの違いについて深掘りしましょう。 ここを間違えるとチーム開発で混乱を招くので、しっかり押さえていきましょう。

いよいよ中盤戦ですね！第4章では例外を「捕まえる（catch）」方法を学びましたが、第5章では逆に例外を「放り投げる」技術について解説します。

似ているようで全く違う、throwとthrowsの使い分けをマスターしましょう。

第5章：例外を投げる技術（throwとthrowsの違い）

概要

自分で例外を発生させるのが「throw」、このメソッドは例外を出すかもしれないと宣言するのが「throws」です。 この章では、呼び出し元に対して「ここから先は君の責任で処理してね」とバトンを渡す仕組みを理解します。

コード抜粋：投げる自分と、宣言するメソッド

public void checkAge(int age) throws IllegalArgumentException {
    if (age < 0) {
        // 1. 自分で例外を生成して投げ飛ばす！
        throw new IllegalArgumentException("年齢にマイナスはありえません");
    }
    System.out.println("年齢は" + age + "歳ですね");
}

逐次解説

1行目：メソッド名の後ろにある throws は「このメソッドを使うときは、この例外に注意してね」という看板（宣言）です。

2行目：if文で、プログラムが想定していない不正なデータ（マイナスの年齢）をチェックします。

4行目：throw（単数形）を使って、実際に例外のインスタンスを生成して投げます。ここでメソッドの実行は即座に中断されます。

6行目：例外が投げられた場合、この行は実行されません。

図解イメージ：手投げ弾と注意看板

この二つの違いは、武器とその取り扱い説明書に例えると分かりやすいです。

  • throw（手投げ弾を投げる）： 「おっと、不正なデータだ！これ以上処理できないぞ」と判断した瞬間に、例外という名の手投げ弾を投げつける行為そのものです。
  • throws（注意看板を立てる）： メソッドの入り口に「この先、手投げ弾（例外）が飛んでくる可能性があります」という看板を立てておくことです。これを見た他のプログラマは、あらかじめ try-catch という防空壕を準備できるようになります。

よくある誤解

「自分で例外を投げると、プログラムが止まってしまうから良くないのでは？」と心配する新人が多いですが、逆です。 ダメなデータがあるのに無理やり処理を続けて、データベースに壊れたデータを書き込んでしまう方が、遥かに恐ろしい事態を招きます。 「これ以上は無理！」と潔く throw するのは、責任感のあるコードの証拠なのです。

実務での重要性

実務では、メソッドの引数をチェックする「バリデーション」で多用します。 また、Checked例外（第3章でやりましたね！）が発生する処理を含むメソッドを作る場合、自分で catch しないなら必ず throws で呼び出し元に伝えなければなりません。これを忘れるとコンパイルエラーになります。

演習問題

  1. throw と throws、実際に例外を発生させる（インスタンスを投げる）のはどちらのキーワードですか？
  2. メソッドに throws Exception と書いてある場合、そのメソッドを呼び出す側はどのような対応をする必要がありますか？

「投げる」と「宣言する」、この2つの動詞を使い分けられるようになれば、メソッド間の連携がグッとスムーズになります。

次は、投げられた例外がどのように呼び出し元を遡っていくのか、その仕組みである「スタックトレースと例外伝播」について見ていきましょう。

第5章で「例外を投げる」方法を学びましたが、投げられた例外は一体どこへ行くのでしょうか？ 第6章では、エラーが発生した瞬間にバックグラウンドで何が起きているのか、その「足跡」を辿る技術を解説します。

第6章：エラーの足跡を辿る（スタックトレースと例外伝播）

概要

例外が発生すると、それは呼び出し元のメソッドへと次々に伝わっていきます。これを「例外伝播」と呼びます。 この章では、エラーメッセージでよく見かける謎の長文「スタックトレース」を読み解き、どこでトラブルが起きたのかを特定するプロのデバッグ手法を学びます。

コード抜粋：メソッドを突き抜ける例外

public void methodA() {
    methodB();
}

public void methodB() {
    methodC();
}

public void methodC() {
    // ここで爆発！
    int error = 10 / 0;
}

逐次解説

1行目：methodAが呼ばれ、そこからmethodBが呼び出されます。

5行目：methodBが呼ばれ、さらに奥のmethodCを呼び出します。

9行目：methodCで例外（ArithmeticException）が発生します。

11行目：methodCにはcatchがないため、例外は呼び出し元のmethodBに飛び火します。

12行目：methodBにもcatchがないので、さらにmethodAへ、最終的にはmainメソッドや実行環境へと伝わります。これが「例外伝播」です。

図解イメージ：積み重なる本棚（コールスタック）

Javaのメソッド呼び出しは、本を積み重ねていく「スタック」という構造で管理されています。

  1. 一番下に「mainメソッド」という本を置く
  2. その上に「methodA」の本を置く
  3. さらに「methodB」、「methodC」と積み上げる

methodCでエラーが起きたとき、一番上の本が燃え上がります。もしmethodCに消火器（catch）がなければ、火はすぐ下のmethodBの本に移ります。 この「どの本（メソッド）を順に辿って火が燃え広がったか」の記録が、スタックトレースです。

よくある誤解

スタックトレースを見ると、英語の羅列に圧倒されて「うわっ、難しそう！」と画面を閉じてしまう人がいます。 しかし、実は一番上（あるいは上の方）に書いてある行こそが「犯行現場（エラーが起きた場所）」です。 自分のプロジェクトのパッケージ名が書いてある行を探すだけで、原因の8割は見つかったも同然ですよ！

実務での重要性

実務で不具合報告を受けたとき、エンジニアが真っ先に要求するのがこのスタックトレースです。 「どこで、どのメソッドを経由して、何の例外が起きたか」がすべて記録されているため、これさえあれば自分の手元で再現しなくても原因の目星がつきます。スタックトレースは、システムからの「遺言」のような大切な情報なのです。

演習問題

  1. 呼び出し元のメソッドすべてにcatchブロックがなかった場合、投げられた例外はどうなりますか？
  2. スタックトレースを読むとき、最初に見るべきなのは「一番上の行」と「一番下の行」のどちらでしょうか？

エラーの通り道が見えてきましたね！「どこで起きたか」が分かれば、もう怖いものはありません。

いよいよ次が最終章です。 実務で絶対にやってはいけない「例外の握りつぶし」というアンチパターンと、自分たちでエラーを定義する「カスタム例外」についてお話しして、この研修を締めくくりましょう。

いよいよ最終章です！ここまで、例外の仕組みや投げ方をマスターしてきましたね。 最後は、現場で一目置かれるエンジニアになるための「設計の作法」と、絶対にやってはいけない「禁じ手」についてお話しします。

第7章：実践！カスタム例外とアンチパターン（例外を握り潰さないために）

概要

Javaが用意してくれている例外（既存のException）だけでは、業務上のエラーを表現しきれないことがあります。 この章では、自分たちのルールで作る「カスタム例外」の作り方と、初心者が最も陥りやすい「例外の握り潰し」の危険性について学びます。

コード抜粋：カスタム例外と禁じられた書き方

// 1. カスタム例外の定義
class BalanceShortageException extends Exception {
    public BalanceShortageException(String message) {
        super(message);
    }
}

// 2. 絶対にやってはいけない「握り潰し」
public void withdraw(int amount) {
    try {
        // 残高チェックなどの処理
    } catch (Exception e) {
        // 何もしない（空っぽ） ← これが「握り潰し」！
    }
}

逐次解説

1行目：独自の例外クラスを定義します。Exceptionを継承することで、Checked例外として機能します。

2行目：クラス名は「何が起きたか」が一目でわかる名前にするのがコツです（例：残高不足例外）。

10行目：tryの中でエラーが起きるかもしれない処理を書きます。

11行目：catchでエラーを捕まえますが……。

13行目：中身が空っぽです！エラーが起きたという事実が、この世から消し去られてしまいました。

図解イメージ：火災報知器の電池を抜く

「例外の握り潰し」を現実で例えると、火災報知器が鳴った瞬間に、うるさいからといって電池を抜いて二度寝するようなものです。

エラー（火）は消えていません。ただ「知らせ（音）」を消しただけです。 これをしてしまうと、後で建物（システム）が全焼したときに、なぜ火が出たのか、いつから燃えていたのかが誰にも分からなくなってしまいます。

よくある誤解

「とりあえず動けばいいから、コンパイルエラーが出ないように中身を空にしておこう」という誘惑は非常に強力です。 しかし、握り潰されたエラーは、後になってから「全く関係のない場所」で別の不具合として現れます。 デバッグに数日を費やした結果、原因が数日前に握り潰した一行のせいだった……というのは、開発現場でよくある悲劇です。

実務での重要性

実務では、catchしたら最低限「ログ（記録）」を出力しましょう。 e.printStackTrace(); を書くだけでも、未来の自分やチームメイトを救うことになります。 また、カスタム例外を使うことで、呼び出し側のエンジニアに「あ、これは銀行の残高不足の時の処理だな」と、コードの意図を明確に伝えることができます。

演習問題

  1. 例外をキャッチした際に、中身を空にせず、最低限行うべきことは何ですか？
  2. BalanceShortageException を RuntimeException ではなく Exception を継承して作る理由はなぜでしょうか？（第3章を思い出してみましょう）

学習の指針：エラーを「味方」にするために

お疲れ様でした！これで例外処理の基礎から応用まで、一通りの地図を手に入れましたね。 これからの学習では、以下のステップを意識してみてください。

  • ステップ1：自分で書いたコードで、あえてエラーを起こしてみる。そしてスタックトレースを一番上から読んでみる。
  • ステップ2：Javaの標準API（StringやListなど）のドキュメントを読み、どんな時にどんなRuntimeExceptionが投げられるのかを観察する。
  • ステップ3：try-with-resources という、より洗練されたリソース解放の書き方を調べて、第4章の知識をアップデートする。

例外は、プログラムを壊す「敵」ではありません。 あなたの作ったシステムが、過酷な現実世界（ネットワーク断線、ユーザーの誤入力など）で生き残るための「鎧（よろい）」なのです。

これからも、恐れずにたくさんエラーを出して、強いエンジニアになっていきましょう！

セイ・コンサルティング・グループでは新人エンジニア研修のアシスタント講師を募集しています。

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。
対象読者
新人エンジニア研修講師
前の記事
Javaエンジニアへの第一歩！Stringクラスの内部構造を解き明かすNew!!
2026年3月19日