ホーム / Rust /

Rustのエラーハンドリング入門｜Resultとpanic!を使いこなす

2025年4月21日月曜日

Rust

Rustのエラーハンドリング、なんだか難しそう…と感じていませんか？ 

Rustを始めたばかりの頃は、コンパイル時のメッセージに「むむ？」となったり、予期せぬプログラム終了に「あれれ？」となったりすることも少なくないかもしれませんね。大丈夫、誰もが通る道です！

Rustのエラー処理は、他の言語とは少し考え方が異なり、特に Result<T, E> や panic! は、Rustの安全性を支える仕組みです。最初はちょっと戸惑うかもしれませんが、一度理解してしまえば、とっても頼りになる相棒になってくれますよ。

この記事では、Rustのエラーハンドリングの基本的な考え方から、Result<T, E>型、panic!マクロ、そして便利な?演算子の使い方まで、実際のコード例をたっぷり交えながら、「なるほど！」と思っていただけるように解説していきます。

この記事で学べること

  • Rustのエラーハンドリングの基本的な考え方
  • 回復不能なエラーとpanic!マクロの役割・使い方
  • 回復可能なエラーとResult<T, E>型の役割・使い方
  • Resultを処理するmatch, unwrap, expectの違い
  • エラー処理をスッキリ書ける?演算子の使い方
  • 状況に応じたエラー処理方法の選び方の指針

Rustのエラーハンドリングとは？

まず、Rustがエラーをどう扱っているか、その基本的な考え方から見ていきましょう。

多くのプログラミング言語には「例外（Exception）」という仕組みがあって、エラーが起きたら「ポーン！」と例外を投げて、どこかでキャッチする、みたいな流れが一般的です。でも、Rustには基本的に例外がありません。

じゃあどうするの？というと、Rustはエラーを大きく2つの種類に分けて考えます。

  • 回復不能なエラー (Unrecoverable Errors)
    プログラムのバグなど、どうしようもない致命的な問題。これが起きたら、プログラムはパニックを起こして停止します。使うのは panic! マクロです。
  • 回復可能なエラー (Recoverable Errors)
    ファイルが見つからない、ネットワークに繋がらないなど、予期できる可能性のあるエラー。プログラムは停止せず、エラーが起きたことを呼び出し元に伝え、対処を促します。使うのは Result<T, E> 型です。

Rustでは、特に回復可能なエラーを型システムを使って表現することで、コンパイラが「おい、エラー処理忘れてるぞ！」と教えてくれるんです。

おかげで、うっかりエラー処理を忘れることが減り、より安全で堅牢なプログラムを作りやすくなっています。

回復不能なエラーと`panic!`マクロ【Rustのエラーハンドリング】

さて、まずは「回復不能なエラー」と、その際に登場する panic! マクロについてです。

panic! は、プログラムが「もうダメだ！お手上げ！」となったときに発生します。基本的にはプログラムのバグを示していて、発生するとプログラムは強制的に終了し、エラーメッセージを表示して止まります。

例えば、配列の範囲外にアクセスしようとした時など、予期しない問題が起きた際に自動的に panic! が発生することがあります。また、開発者が意図的に panic! を呼び出すことも可能です。

`panic!`マクロの使い方と発生する状況

panic! マクロを意図的に呼び出すのはとても簡単です。メッセージを指定して呼び出すだけ。

書き方

panic!("ここにパニックメッセージを書きます");

ソースコード

fn main() {
    oh_no();
    println!("ここは実行されません"); // panic! の後なので表示されない
}

fn oh_no() {
    panic!("大変だ！パニック発生！");
}

ソースコードの表示結果 (実行環境により多少表示は異なります)

thread 'main' panicked at '大変だ！パニック発生！', src/main.rs:7:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

このように、指定したメッセージと共にプログラムが停止します。

また、unwrap() や expect() といったメソッド（後で説明します）が失敗した場合も、内部で panic! が発生します。panic! が発生すると、基本的にそのスレッドの処理はそこでストップします。

`panic!`マクロを意図的に使うべき場面は限定的

panic! は強力ですが、むやみに使うものではありません。

なぜなら、panic! が発生するとプログラムが止まってしまうため、呼び出し元でエラーから回復するチャンスがなくなってしまうからです。

特にライブラリ（他の人が使う部品）を作るときに panic! を起こしてしまうと、そのライブラリを使う側のプログラムまで巻き込んで停止させてしまう可能性があります。

じゃあ、いつ使うの？というと、主に以下のような場面です。

  • どうしても回復しようがない、プログラム自体の明らかなバグを示すとき
  • テストコードの中で、失敗したことを明確に示したいとき
  • プロトタイプ（試作品）開発などで、まだちゃんとしたエラー処理を書く前の仮実装として使うとき

普段のアプリケーション開発では、可能な限り次に紹介する Result<T, E> を使って、回復可能なエラーとして扱うことを考えましょう。panic! は本当にどうしようもない時の最後の手段、と覚えておくと良いでしょう。

回復可能なエラーと`Result<T, E>`型【Rustのエラーハンドリング】

お待たせしました！Rustのエラーハンドリングの主役、Result<T, E> 型の登場です。

Result は「回復可能なエラー」、つまり、プログラムの実行中に起こるかもしれないけど、致命的ではなく、適切に対処すればプログラムを続けられる種類のエラーを表現するために使われます。

例えば、

  • ユーザーが指定したファイルを開こうとしたけど、そのファイルが存在しなかった
  • ネットワーク経由でデータを取得しようとしたけど、サーバーから応答がなかった
  • 文字列を数値に変換しようとしたけど、数字以外の文字が含まれていた

といった状況です。これらのエラーが発生しても、プログラム全体を止める必要はありませんよね？「ファイルがないなら、エラーメッセージを表示する」「サーバーから応答がないなら、少し待ってから再試行する」といった対処が考えられます。

Result<T, E> は、このような「成功」か「失敗」かの二つの可能性を持つ結果を表現するための型です。具体的には、Ok(T) と Err(E) という二つのバリアント（種類）を持つ列挙型（enum）として定義されています。

  • Ok(T): 処理が成功したことを示す。T には成功した場合の値が入る。
  • Err(E): 処理が失敗したことを示す。E には失敗の理由を示すエラー情報が入る。

Rustの標準ライブラリの多くの関数は、失敗する可能性がある場合、この Result 型を返します。おかげで、関数を使う側は「あ、この関数は失敗する可能性があるんだな」と分かり、コンパイラもエラー処理を忘れていないかチェックしてくれるのです。

`Result<T, E>`型の基本的な構造と使い方

Result<T, E> は列挙型（enum）だと説明しました。具体的には、標準ライブラリで以下のように定義されています。（簡略化したイメージです）

enum Result<T, E> {
    Ok(T),  // 成功。T型の値を持つ
    Err(E), // 失敗。E型の値（エラー情報）を持つ
}

T は成功した時の値の型（例えば、ファイルの内容を読む関数なら String）、E は失敗した時のエラー情報の型（例えば、ファイルオープンエラーなら std::io::Error）を表します。

簡単な例として、数値を文字列で受け取り、偶数なら成功 (Ok)、奇数なら失敗 (Err) を返す関数を考えてみましょう。

// i32（整数）を受け取り、偶数なら Ok(i32)、奇数なら Err(String) を返す関数
fn check_even(num: i32) -> Result<i32, String> {
    if num % 2 == 0 {
        Ok(num) // 成功！元の数値を Ok で包んで返す
    } else {
        Err(String::from("奇数です！")) // 失敗！エラーメッセージを Err で包んで返す
    }
}

fn main() {
    let result1 = check_even(10);
    let result2 = check_even(7);

    println!("10をチェックした結果: {:?}", result1);
    println!(" 7をチェックした結果: {:?}", result2);
}

表示結果

10をチェックした結果: Ok(10)
 7をチェックした結果: Err("奇数です！")

このように、関数の戻り値の型として Result<成功時の型, エラー時の型> を指定し、処理結果に応じて Ok(値) または Err(エラー値) を返します。関数のシグネチャ（型定義）を見るだけで、失敗する可能性があることが一目瞭然ですね。

`Result<T, E>`型を処理する基本的な方法：`match`式

Result 型の値を受け取ったら、それが Ok なのか Err なのかを判断して、適切な処理を行う必要があります。そのための最も基本的な方法が match 式です。

match 式を使うと、Result の中身が Ok(値) だった場合と Err(エラー) だった場合で、処理をきれいに分岐させることができます。

ソースコード (前の `check_even` 関数を使った例)

fn main() {
    let numbers = vec![4, 7, 8];

    for num in numbers {
        let result = check_even(num); // Result<i32, String> が返ってくる

        match result {
            Ok(n) => {
                // Ok(値) だった場合の処理
                println!("{} は偶数です！やったね！", n);
            }
            Err(e) => {
                // Err(エラー) だった場合の処理
                println!("{} は... おっと、エラー: {}", num, e);
            }
        }
    }
}

// check_even 関数は前の例と同じ
fn check_even(num: i32) -> Result<i32, String> {
    if num % 2 == 0 {
        Ok(num)
    } else {
        Err(String::from("奇数です！"))
    }
}

表示結果

4 は偶数です！やったね！
7 は... おっと、エラー: 奇数です！
8 は偶数です！やったね！

match 式の良いところは、考えられる全ての可能性（Ok と Err）を網羅しないと、コンパイラが警告を出してくれる点です。おかげで、「エラーの場合の処理を書き忘れちゃった！」というミスを防ぎやすくなります。これが Rust の安全性を高めている理由の一つです。

`Result<T, E>`型を処理する便利なメソッド：`unwrap()` と `expect()`

match は丁寧ですが、毎回書くのは少し面倒な場合もあります。そんな時、もっと手軽に Result の中身を取り出すメソッドも用意されています。ただし、使い方には注意が必要です。

  • unwrap()
    Result が Ok(値) なら中の値を取り出します。もし Err(エラー) だったら、panic! を発生させてプログラムを終了させます。
  • expect("エラーメッセージ")
    unwrap() と似ていますが、Err で panic! する際に、指定したカスタムメッセージを表示してくれます。
fn main() {
    let good_result: Result<i32, String> = Ok(100);
    let bad_result: Result<i32, String> = Err(String::from("何か問題が発生"));

    // Ok の場合は値が取り出せる
    let value = good_result.unwrap();
    println!("unwrap成功: {}", value);

    // expect も Ok なら成功
    let value_expected = Ok::<i32, String>(200).expect("ここはpanicしないはず");
    println!("expect成功: {}", value_expected);
    
    // Err に対して unwrap を使うと panic する
    // let bad_value = bad_result.unwrap(); // ここで panic!

    // Err に対して expect を使うと、指定したメッセージで panic する
    let bad_value_expected = bad_result.expect("expect で指定したエラーメッセージ");
    // プログラムは↑の行で panic して停止する
}

unwrap() や expect() はコードが短くなるので便利に見えますが、Err だった場合に問答無用でプログラムが停止してしまうというリスクがあります。

テストコードや、絶対に失敗しないと確信できる場面、あるいは失敗したら即座にプログラムを止めるべき場面以外では、安易に使わない方が賢明です。

特に expect() は、なぜ panic! するのか理由を明確に示せる点で unwrap() よりは親切ですが、それでも panic! であることに変わりはありません。基本は match や、次に出てくる ? 演算子を使うのがおすすめです。

エラー伝播を簡潔にする `?` 演算子【Rustのエラーハンドリング】

関数の中で別の関数を呼び出し、その関数が Result を返す場合、エラーが起きたらそのエラーをそのまま呼び出し元に伝えたい（エラーを上に「伝播」させたい）場面がよくあります。

例えば、ファイルを開いて、その中身を読み取る関数を考えてみましょう。

ファイルを開く操作も、中身を読む操作も、どちらも失敗する可能性があります（Result を返します）。もしファイルを開くのに失敗したら、その時点でエラーを呼び出し元に返したいですよね？

match を使うと、こんな感じになります。

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file_long() -> Result<String, io::Error> {
    let f_result = File::open("username.txt");

    let mut f = match f_result {
        Ok(file) => file,
        Err(e) => return Err(e), // エラーなら即座に Err を返す
    };

    let mut s = String::new();

    match f.read_to_string(&mut s) {
        Ok(_) => Ok(s),          // 成功なら Ok(読み取った文字列) を返す
        Err(e) => Err(e),      // エラーなら Err を返す
    }
}

うーん、エラー処理のたびに match を書くのは、ちょっと冗長な感じがしますね。

そこで登場するのが ? 演算子です！
? 演算子は、Result に対するエラー処理の「定型文」を劇的にシンプルにしてくれる、まさに魔法のような演算子です。

Result を返す式の後ろに ? を付けると、以下の処理を自動で行ってくれます。

  • もし Result が Ok(値) なら、Ok を剥がして中の値を取り出す。
  • もし Result が Err(エラー) なら、その Err を、? が使われている関数全体からの戻り値として、即座に返す (return Err(エラー) と同じ)。

これを使うと、さっきの関数は驚くほどスッキリ書けます。

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file_short() -> Result<String, io::Error> {
    let mut f = File::open("username.txt")?; // Errならここでリターン
    let mut s = String::new();
    f.read_to_string(&mut s)?; // Errならここでリターン
    Ok(s) // 両方成功したら Ok(文字列) を返す
}

// さらに短く書くこともできます
fn read_username_from_file_shorter() -> Result<String, io::Error> {
    let mut s = String::new();
    File::open("username.txt")?.read_to_string(&mut s)?;
    Ok(s)
}

どうでしょう？ match を使ったコードと比べて、エラー処理部分が ? だけで済み、本質的な処理（ファイルを開く、読み取る）がずっと見やすくなりましたよね！

? 演算子は、Result を返す関数の中でしか使えませんが、Rustのエラーハンドリングを非常に快適にしてくれる強力な味方です。積極的に活用していきましょう！

`?` 演算子の使い方とサンプルコード

? 演算子の使い方は簡単で、Result<T, E> 型（または Option<T> 型）の値を返す式（関数呼び出しなど）の後ろに ? を付けるだけです。

重要なのは、? 演算子が使えるのは、それを含む関数自身の戻り値の型が Result (または Option) である必要があるということです。? は、Err が発生した場合に、その Err を関数の戻り値として返す（return する）働きをするためです。

簡単な例で動きを見てみましょう。

// 何か失敗するかもしれない処理（ここでは文字列を数値に変換）
fn might_fail(input: &str) -> Result<i32, String> {
    input.parse::<i32>()
        .map_err(|e| format!("数値への変換に失敗しました: {}", e)) // エラー型をStringに変換
}

// ?演算子を使って、失敗する可能性のある処理を呼び出す関数
// この関数自身も Result を返す必要がある
fn process_data(input1: &str, input2: &str) -> Result<i32, String> {
    let num1 = might_fail(input1)?; // input1が数値でない場合、ここでErrが返る
    let num2 = might_fail(input2)?; // input2が数値でない場合、ここでErrが返る

    // 両方成功した場合のみ、以下の処理が実行される
    println!("数値1: {}, 数値2: {}", num1, num2);
    Ok(num1 + num2) // 計算結果を Ok で包んで返す
}

fn main() {
    println!("成功する場合: {:?}", process_data("10", "20"));
    println!("失敗する場合: {:?}", process_data("5", "abc"));
}

ソースコードの表示結果

数値1: 10, 数値2: 20
成功する場合: Ok(30)
失敗する場合: Err("数値への変換に失敗しました: invalid digit found in string")

process_data("5", "abc") の呼び出しでは、might_fail("abc") が Err を返したため、その時点で ? 演算子が働き、process_data 関数全体がその Err を返して終了しています。

println! や Ok(num1 + num2) は実行されません。このように、エラーが発生した時点で処理を中断し、エラー情報を呼び出し元に伝えるのが ? 演算子の役割です。

Rustのエラーハンドリングにおける使い分けの指針

ここまで、panic!、Result<T, E>、match、unwrap/expect、? 演算子を見てきました。では、実際にコードを書くときに、どれをどう使い分ければ良いのでしょうか？

基本的な考え方は、最初に説明した「回復不能か、回復可能か」で判断することです。

以下に簡単な判断のフローを示します。

  1. そのエラーは、プログラムのバグなど、絶対に起こるべきではない致命的な問題ですか？
    • はい → panic! を検討します。ただし、ライブラリ開発などでは極力避け、アプリケーションの「ここが壊れたらもう続行不能」という箇所に限定するのが良いでしょう。テストコードで失敗を示すのにも使えます。
    • いいえ → 次へ進みます。
  2. そのエラーは、予期される可能性のある問題（ファイルがない、入力形式が違うなど）で、プログラムが対処すべきものですか？
    • はい → Result<T, E> を使うのが基本です。これがRust流のエラーハンドリングの王道です。
    • いいえ（例えば、単に値が存在しない可能性がある場合など）→ Option<T> 型が適しているかもしれません。（Option は「値がある(Some)か、ない(None)か」を表現する型で、エラー処理と似た場面で使われますが、今回は深入りしません）
  3. Result を返す関数を呼び出した後、どう処理しますか？
    • エラーが起きたら、そのエラーをさらに呼び出し元に伝えたい（エラーを伝播させたい）→ ? 演算子を使いましょう。コードが劇的にシンプルになります。
    • エラーが起きた場合と成功した場合で、その場で具体的な処理を分岐させたい → match 式を使います。最も丁寧で安全な方法です。
    • 「絶対に失敗しないはず！」と確信がある場合や、簡単なサンプルコード、失敗したら即プログラムを止めたい場合 → unwrap() や expect() も使えますが、リスクを理解した上で使いましょう。expect() で理由を明記するのがおすすめです。

基本方針は「可能な限り Result を使い、? でエラー伝播を簡潔にし、必要に応じて match で処理する」と考えておくと、多くの場面でうまく対応できるはずです。

【まとめ】堅牢なRustコードを書くために

お疲れ様でした！今回は、Rustのエラーハンドリングの基本について、panic! と Result<T, E> を中心に、match 式、unwrap() / expect()、そして便利な ? 演算子まで見てきました。

ポイントをおさらいしましょう。

  • Rustはエラーを「回復不能（panic!）」と「回復可能（Result）」に分けて考える。
  • panic! は致命的なバグを示し、プログラムを停止させる。多用は避けるべき。
  • Result<T, E> は失敗する可能性のある処理の結果を示し、Ok(値) または Err(エラー) を返す。
  • Result の処理は、match 式が基本で安全。
  • unwrap() / expect() は手軽だが panic! のリスクがある。
  • ? 演算子は Result のエラー伝播を劇的に簡潔にする。積極的に使いたい。
  • 基本は Result を使い、状況に応じて ? や match を使い分ける。

Rustのエラーハンドリングは、最初は少し独特で戸惑うかもしれませんが、慣れてくると、コンパイラの手厚いチェックと相まって、非常にエラーに強いプログラムを書くための強力な武器になります。

今回学んだ知識を活かせば、コンパイルエラーや実行時エラーにも自信を持って対処できるようになるはずです。

これであなたもRustのエラーハンドリングの第一歩を踏み出しました！ぜひ、ご自身のコードで Result や ? を使ってみて、その良さを体感してくださいね！

さらに深く学びたい場合は、自分でカスタムエラー型を定義する方法（thiserror クレートなどを使うと便利です）や、Option と Result の変換などを調べてみると、より洗練されたエラー処理が書けるようになりますよ。

Happy Rusting!

【関連記事】
Rustとは？いま学ぶべき理由と特徴や始め方を詳しく解説

このブログを検索
  • ()

自己紹介

自分の写真
リモートワークでエンジニア兼Webディレクターとして活動しています。プログラミングやAIなど、日々の業務や学びの中で得た知識や気づきをわかりやすく発信し、これからITスキルを身につけたい人にも役立つ情報をお届けします。 note → https://note.com/yurufuri X → https://x.com/mnao111

QooQ