はい、承知いたしました。RustのResult型について、約5000語の詳細な入門記事を作成します。

RustのResult型入門: 安全なエラーハンドリングを学ぼう

はじめに

プログラミングにおいて、エラーハンドリングは避けて通れない重要な課題です。ファイルが見つからない、ネットワーク接続に失敗する、ユーザーが無効な入力をする、あるいは計算がオーバーフローするなど、プログラムの実行中には様々な問題が発生し得ます。これらの予期しない、あるいは予期されるが望ましくない状況に適切に対処できなければ、プログラムはクラッシュしたり、誤った結果を生成したり、セキュリティ上の脆弱性を生んだりします。

多くのプログラミング言語では、エラーハンドリングのために「例外（Exceptions）」というメカニズムを採用しています。例外は、エラーが発生した場所から処理をジャンプさせ、コールスタックを遡って適切なハンドラに制御を移します。これはコードを簡潔にする一方で、「どの関数がどんな例外を投げるか」が関数のシグネチャからは分かりにくい、例外の捕捉漏れがコンパイル時には検出されにくい、といった問題を引き起こすことがあります。

Rustは、より安全で明示的なプログラミングを目指す言語です。そのため、Rustは例外を回復不可能なエラー（パニック）のためにのみ使用し、回復可能なエラーのハンドリングには別の仕組みを提供します。その中心となるのが、本記事で詳しく掘り下げるResult型です。

Result型は、関数が成功した場合はその結果を、失敗した場合はその原因となるエラーを、関数の戻り値として明示的に伝えるための型です。これにより、プログラマは関数がエラーを返す可能性があることをコンパイル時に知り、そのエラーを必ず処理するようコンパイラに促されます。これにより、エラーの見落としや不適切な処理を防ぎ、より堅牢で信頼性の高いプログラムを作成することができます。

この記事では、Rustにおけるエラーハンドリングの哲学から始め、Result型の基本的な使い方、便利なメソッド、エラー伝播のメカニズム（特に?演算子）、独自エラー型の定義方法、そして他のエラーハンドリング手法との比較やベストプラクティスまで、Result型を使いこなすために必要な知識を網羅的に解説します。この記事を読めば、あなたはRustで安全かつ効果的なエラーハンドリングを行う自信を得られるでしょう。

さあ、Rustのエラーハンドリングの世界に深く潜り込んでいきましょう。

なぜエラーハンドリングが重要なのか？

エラーハンドリングがなぜ重要なのか、改めて考えてみましょう。

プログラムの堅牢性（Robustness）: 適切にエラーハンドリングされたプログラムは、予期しない状況や無効な入力に対しても、クラッシュしたり異常終了したりすることなく、穏便に対処することができます。例えば、ファイルが存在しない場合、プログラムは単に終了するのではなく、「ファイルが見つかりません」というメッセージを表示してユーザーに知らせることができます。
ユーザー体験（User Experience）: ユーザーは、プログラムが突然停止したり、意味不明なエラーメッセージを表示したりすることを嫌います。分かりやすいエラーメッセージや、エラーからの回復手段を提供することで、ユーザー体験は大きく向上します。
デバッグと保守性（Debugging and Maintainability）: エラーが発生した際に、その原因や発生状況が正確に記録・報告されると、開発者は問題の特定と修正を容易に行えます。また、エラーハンドリングのロジックが明確に記述されているコードは、他の開発者にとっても理解しやすく、保守が容易になります。
セキュリティ（Security）: 不適切なエラーハンドリングは、セキュリティ上の脆弱性を生む可能性があります。例えば、詳細すぎるエラー情報（データベースのスキーマ情報など）を外部に漏らしてしまったり、エラーによって特定のチェックがスキップされたりすることが考えられます。
リソース管理（Resource Management）: ファイルやネットワーク接続、メモリなどのリソースは、エラー発生時にも適切に解放される必要があります。Rustの所有権システムはこれを助けますが、エラー発生パスでもリソースがリークしないように注意が必要です。

これらの理由から、エラーハンドリングはプログラムの機能を実装することと同様に、あるいはそれ以上に、品質の高いソフトウェアを開発する上で不可欠な要素です。

Rustのエラーハンドリング哲学

Rustは安全性を第一に設計された言語であり、その哲学はエラーハンドリングにも色濃く反映されています。Rustのエラーハンドリングの基本的な考え方は以下の通りです。

エラーは値である: Rustでは、エラーは特別なイベントや状態ではなく、成功の結果と同じように、関数の戻り値として扱われる「値」です。これにより、エラーを他のデータと同じように操作したり、保存したり、関数間で受け渡したりできます。
回復可能なエラー vs. 回復不可能なエラー:
- 回復可能なエラー (Recoverable Errors): プログラムが検出して、それに基づいて何らかの対処ができるエラー（例: ファイルが見つからない、ネットワーク接続が切断された）。RustではこれらのエラーをResult型で表現し、明示的なハンドリングを要求します。
- 回復不可能なエラー (Unrecoverable Errors): プログラムが続行できないほど深刻な問題で、通常はプログラムのバグを示唆するエラー（例: 配列の範囲外アクセス、Nullポインタ参照 (RustにはNullはありませんが、概念として)、不変条件の違反）。Rustではこれらのエラーを「パニック（Panic）」として扱い、プログラムを強制終了させることが多いです。panic!マクロや、unwrap()、expect()メソッドの失敗によって発生します。
明示的なエラー伝播: 関数がエラーを返す可能性がある場合、それは関数のシグネチャ（戻り値の型）に明示的に示されます。これにより、呼び出し元はエラーが発生しうることを認識し、そのエラーを処理するか、さらに上位の呼び出し元に伝播させるかを強制的に決定させられます。コンパイラは、Result型が返された場合にそのErrバリアントが処理されることを検証します。
コンパイル時保証: Rustコンパイラは、開発者がResult型のErrバリアントを無視していないかをチェックします。これにより、エラーの捕捉漏れといったヒューマンエラーをコンパイル時点で防ぐことができます。

この哲学に基づき、Rustのエラーハンドリングは非常に安全かつ信頼性の高いものとなっています。そして、その中心的な役割を担うのが、これから詳しく見ていくResult型なのです。

Result型とは何か？

Result型は、Rust標準ライブラリで定義されている列挙型（enum）です。その定義は非常にシンプルです。

rust enum Result<T, E> { Ok(T), Err(E), }

この定義は、「Result型は、ジェネリックな型Tの値を保持するOkバリアント、またはジェネリックな型Eの値を保持するErrバリアントのいずれかである」ことを示しています。

Ok(T): 処理が成功した場合を表します。成功して得られた結果の値は、型TのデータとしてOkバリアントの中に格納されます。
Err(E): 処理が失敗した場合を表します。失敗の原因となったエラー情報は、型EのデータとしてErrバリアントの中に格納されます。

ここで重要なのは、Result型が成功の値 (T) と エラーの値 (E) の両方を保持する可能性があることを、型システムとして表現している点です。関数の戻り値の型がResult<T, E>である場合、その関数はT型の値を返す可能性があると同時に、E型の値を返す可能性もあることをコンパイラと他の開発者に明確に伝えます。

なぜOption型だけでは不十分なのか？

Rustには、値が存在するか、あるいは存在しないかを表すOption<T>型もあります。Option<T>はSome(T)とNoneのバリアントを持ち、Noneは値が存在しないことを示します。

rust enum Option<T> { Some(T), None, }

Option型は、値の欠落を表すには非常に便利です（例: マップからのキー検索、リストの先頭要素）。しかし、処理が失敗した「理由」を伝えたい場合には不十分です。

例えば、ファイルを読み込もうとして失敗した場合、Option<String>を返してNoneで失敗を示すことはできます。しかし、その失敗が「ファイルが存在しない」ためなのか、「読み込み権限がない」ためなのか、「ファイルが壊れている」ためなのか、Noneだけでは分かりません。

一方、Result<String, std::io::Error>のような型を返せば、成功した場合はファイルの内容(String)をOkで返し、失敗した場合はその詳細な原因（std::io::Errorにはファイルが見つからない、権限エラーなどの情報が含まれています）をErrで返すことができます。

したがって、単に値の有無を示す場合はOptionを、処理の成功/失敗とその原因を示す場合はResultを使用するのが、Rustにおける一般的な使い分けです。

Result型の基本的な使い方

Result型から成功した値またはエラー値を取り出すには、主にmatch式やif let構文を使用します。これらの構文は、Result型が持つ二つの可能性（OkかErrか）を網羅的に処理することをコンパイラに保証させます。

`match` 式を使ったエラーハンドリング

最も基本的なResult型の処理方法はmatch式を使うことです。match式はResult型の値をパターンマッチングし、Okの場合とErrの場合とで異なる処理を実行します。

“`rust
use std::fs::File;
use std::io::prelude::*;
use std::path::Path;

fn read_file_content(file_path: &Path) -> Result {
// ファイルを開く操作はResultを返す
let file_result = File::open(file_path);

match file_result {
    // ファイルオープンが成功した場合
    Ok(mut file) => {
        let mut contents = String::new();
        // ファイル内容の読み込み操作もResultを返す
        let read_result = file.read_to_string(&mut contents);

        match read_result {
            // 読み込みが成功した場合
            Ok(_) => Ok(contents), // ファイル内容をOkバリアントで返す
            // 読み込みが失敗した場合
            Err(err) => Err(err), // 読み込みエラーをErrバリアントで返す
        }
    },
    // ファイルオープンが失敗した場合
    Err(err) => Err(err), // オープンエラーをErrバリアントで返す
}

}

fn main() {
let path = Path::new(“hello.txt”);

let content_result = read_file_content(path);

match content_result {
    Ok(content) => {
        println!("ファイル内容:\n{}", content);
    },
    Err(err) => {
        // エラーの種類によって異なるメッセージを表示することも可能
        match err.kind() {
            std::io::ErrorKind::NotFound => {
                eprintln!("エラー: ファイル '{}' が見つかりませんでした。", path.display());
            },
            std::io::ErrorKind::PermissionDenied => {
                eprintln!("エラー: ファイル '{}' へのアクセスが拒否されました。", path.display());
            },
            _ => {
                eprintln!("エラー: ファイル '{}' の読み込み中にエラーが発生しました: {}", path.display(), err);
            },
        }
    },
}

}
“`

この例では、read_file_content関数はResult<String, std::io::Error>を返します。

File::open(file_path)はResult<File, std::io::Error>を返します。
最初のmatch file_resultで、ファイルが開けたか開けなかったかを判定します。
Ok(mut file)の場合は、ファイルオブジェクトfileを取得し、read_to_stringを呼び出します。これもResult<usize, std::io::Error>を返します。（読み込んだバイト数を返しますが、ここでは無視しています）。
二番目のmatch read_resultで、読み込みが成功したか失敗したかを判定します。
Ok(_)の場合は、ファイル内容がcontentsに入っているので、Ok(contents)として関数の最終結果とします。
Err(err)の場合は、そのエラーerrをそのままErr(err)として関数の最終結果とします。
最初のmatch file_resultでErr(err)だった場合も、そのエラーerrをそのままErr(err)として関数の最終結果とします。

main関数では、read_file_contentが返したResultをmatchしています。Ok(content)であればファイル内容を表示し、Err(err)であればエラーメッセージを表示しています。さらに、std::io::Errorが持つkind()メソッドを使って、エラーの種類（ファイルが見つからない、権限エラーなど）に応じたより具体的なメッセージを表示しています。

このコードは冗長に見えるかもしれませんが、Result型をmatchすることで、成功と失敗の両方のケースを網羅的に、かつ明示的に処理していることが分かります。コンパイラは、matchがResult型のすべてのバリアント（OkとErr）を処理していることを検証するため、エラーの捕捉漏れを防ぐことができます。

`if let` を使ったResult型のチェック

match式は網羅的なパターンマッチングが必要な場合に強力ですが、単に「成功した場合だけ処理したい」とか「特定のエラーの場合だけ処理したい」といった場合には、if let構文を使うとより簡潔に書けます。

“`rust
fn process_file_if_ok(file_path: &Path) {
let file_result = File::open(file_path);

// ファイルオープンが成功した場合のみ処理
if let Ok(mut file) = file_result {
    let mut contents = String::new();
    if file.read_to_string(&mut contents).is_ok() {
        println!("ファイル内容の読み込みに成功しました:\n{}", contents);
    } else {
        // read_to_string がErrを返した場合の処理 (省略可能)
        eprintln!("ファイル内容の読み込みに失敗しました。");
    }
} else {
    // ファイルオープンがErrを返した場合の処理 (省略可能)
    eprintln!("ファイルのオープンに失敗しました。");
}

}

fn log_error_if_not_found(file_path: &Path) {
let file_result = File::open(file_path);

// ファイルオープンがErrで、かつErrorKindがNotFoundの場合のみ処理
if let Err(err) = file_result {
    if err.kind() == std::io::ErrorKind::NotFound {
        eprintln!("WARN: ファイル '{}' が見つかりませんでした。処理をスキップします。", file_path.display());
    } else {
        // その他のエラーの場合の処理 (省略可能)
        eprintln!("ERROR: ファイル '{}' のオープン中に予期しないエラーが発生しました: {}", file_path.display(), err);
    }
}

}
“`

if letはResult型の特定バリアント（OkまたはErr）の場合にのみブロック内のコードを実行したい場合に便利です。しかし、これはmatchのように「成功したらA、失敗したらB」といった網羅的な処理を強制するものではないため、エラーハンドリングにおいては、通常はmatchを使うか、後述する?演算子を使う方が一般的です。

Result型の便利なメソッド

Result型には、エラーハンドリングをより柔軟かつ簡潔に行うための様々なメソッドが実装されています。ここでは、特によく使われるメソッドを紹介します。

状態の確認: `is_ok()`, `is_err()`

ResultがOkバリアントかErrバリアントかをブール値で判定します。

“`rust
let result: Result = Ok(10);
println!(“Is OK? {}”, result.is_ok()); // 出力: Is OK? true
println!(“Is ERR? {}”, result.is_err()); // 出力: Is ERR? false

let error_result: Result = Err(“something went wrong”);
println!(“Is OK? {}”, error_result.is_ok()); // 出力: Is OK? false
println!(“Is ERR? {}”, error_result.is_err()); // 出力: Is ERR? true
“`

これらのメソッドは、Resultの状態を確認するのに便利ですが、これらの後にResultの値を取り出すには、通常matchやif letを使う必要があります。安易にunwrap()などを呼び出すと危険です。

値の取り出し（パニックする可能性あり）: `unwrap()`, `expect()`

unwrap()メソッドは、ResultがOkバリアントの場合はその中の値を返し、Errバリアントの場合は現在のスレッドをパニックさせます。

“`rust
let ok_result: Result = Ok(100);
let value = ok_result.unwrap(); // 成功するので 100 を返す
println!(“Value: {}”, value); // 出力: Value: 100

let err_result: Result = Err(“division by zero”);
// 失敗するのでパニックする！
// let value = err_result.unwrap();
// println!(“This line will not be reached”);
“`

expect(message: &str)メソッドはunwrap()と似ていますが、Errバリアントの場合にパニックメッセージを指定できます。unwrap()よりも、なぜパニックしたのかがメッセージで分かりやすいため、デバッグ用途ではexpect()の方が推奨されることがあります。

rust let err_result: Result<i32, &str> = Err("file not found"); // 失敗するのでパニックする！指定したメッセージが表示される // let value = err_result.expect("Failed to read configuration file");

警告: unwrap()やexpect()は、そのResultが絶対にErrにならないと確信できる場合（例えば、テストコードや非常に単純で制御された状況）や、エラーが発生したらプログラムを即時終了させるべき（回復不可能なエラーとみなす）状況以外では使用を避けるべきです。プロダクションコードで安易にこれらを使用すると、予期しないユーザー環境でプログラムがクラッシュする原因となります。Result型を使った安全なエラーハンドリングの最大の利点を損なってしまいます。

Option型への変換: `ok()`, `err()`

ok(): Result<T, E>がOk(T)の場合はSome(T)を、Err(E)の場合はNoneを返します。エラー情報を破棄して、成功値が存在するかどうかだけを知りたい場合に便利です。
err(): Result<T, E>がErr(E)の場合はSome(E)を、Ok(T)の場合はNoneを返します。成功値を破棄して、エラー情報が存在するかどうかだけを知りたい場合に便利です。

“`rust
let ok_result: Result = Ok(123);
let ok_option = ok_result.ok(); // Some(123)
let err_option = ok_result.err(); // None

let err_result: Result = Err(“parse error”.to_string());
let ok_option2 = err_result.ok(); // None
let err_option2 = err_result.err(); // Some(“parse error”.to_string())
“`

成功値/エラー値の変換: `map()`, `map_err()`

map<U, F: FnOnce(T) -> U>(f: F) -> Result<U, E>: Ok(T)の場合に、中の値Tに関数fを適用してUを得て、Ok(U)を返します。Err(E)の場合はそのままErr(E)を返します。成功した場合の値を変換したい場合に便利です。
map_err<F2, G: FnOnce(E) -> F2>(g: G) -> Result<T, F2>: Err(E)の場合に、中の値Eに関数gを適用してF2を得て、Err(F2)を返します。Ok(T)の場合はそのままOk(T)を返します。エラー型を別の型に変換したい場合に便利です。

“`rust
let result: Result = Ok(“100”.to_string());

// 成功値 (String) を別の値 (usize) に変換
let mapped_result: Result = result.map(|s| s.len());
println!(“{:?}”, mapped_result); // 出力: Ok(3)

let error_result: Result = Err(“file not found”);

// エラー値 (&str) を別の値 (String) に変換
let mapped_err_result: Result = error_result.map_err(|s| s.to_uppercase());
println!(“{:?}”, mapped_err_result); // 出力: Err(“FILE NOT FOUND”)
“`

map_errは、特に異なる種類のエラーを単一のカスタムエラー型に統合する際によく使われます。

結果を返すクロージャとの連携: `and_then()`, `or_else()`

これらのメソッドは、前の操作の結果に応じて、さらに別のResultを返す可能性のある操作をチェーンしたい場合に非常に強力です。しばしば「モナディックな操作」と呼ばれます。

and_then<U, F: FnOnce(T) -> Result<U, E>>(f: F) -> Result<U, E>: Ok(T)の場合に、中の値Tを引数に関数fを呼び出し、その結果であるResult<U, E>をそのまま返します。Err(E)の場合はそのままErr(E)を返します。これは、「もし成功したら、次のResultを返す処理に進む」というフローを実現します。
or_else<F2, G: FnOnce(E) -> Result<T, F2>>(g: G) -> Result<T, F2>: Err(E)の場合に、中の値Eを引数に関数gを呼び出し、その結果であるResult<T, F2>をそのまま返します。Ok(T)の場合はそのままOk(T)を返します。これは、「もし失敗したら、エラーハンドリングまたは代替処理としてResultを返す別の処理に進む」というフローを実現します。

“`rust
fn parse_number(s: &str) -> Result {
s.parse::()
}

fn multiply_by_two(n: i32) -> Result {
// ダミーのエラーを返す可能性がある関数
if n > 1000 {
Err(“number too large”.to_string())
} else {
Ok(n * 2)
}
}

let input = “500”;
let result = parse_number(input) // Result
// parse_numberがOkなら、中の値(i32)を使って multiply_by_two を呼び出す
// multiply_by_two は Result を返すので、and_thenの最終的なエラー型はStringに変換される必要がある
// -> ここでエラー型を合わせるために map_err を使う必要がある
.map_err(|e| e.to_string()) // Result に変換
.and_then(|n| multiply_by_two(n)); // Result を返す

println!(“{:?}”, result); // 出力: Ok(1000)

let input_err = “abc”;
let result_err = parse_number(input_err)
.map_err(|e| e.to_string()) // Result に変換
.and_then(|n| multiply_by_two(n)); // parse_numberがErrなので and_then は呼び出されず、そのまま Err(“…”) を返す

println!(“{:?}”, result_err); // 出力: Err(“invalid digit found in string”)

fn find_config() -> Result {
// まずメインの場所を探す
std::fs::read_to_string(“config.main”).map_err(|e| e.to_string())
// メインが見つからなければ、代替の場所を探す
.or_else(|_| std::fs::read_to_string(“config.backup”).map_err(|e| e.to_string()))
}

let config_content = find_config();
println!(“{:?}”, config_content);
“`

and_thenは、一連のフォールブル（失敗しうる）な操作をパイプラインのように繋ぐ際によく使われます。ただし、異なる種類のエラーを扱う場合は、map_errを使ってエラー型を統一する必要が出てくることに注意が必要です。or_elseは、エラーが発生した場合に代替手段を試す場合に便利です。

デフォルト値を返す: `unwrap_or()`, `unwrap_or_else()`

unwrap_or(default: T) -> T: Ok(T)の場合はその中の値Tを返し、Err(E)の場合は引数で指定されたデフォルト値defaultを返します。
unwrap_or_else<F: FnOnce(E) -> T>(f: F) -> T: Ok(T)の場合はその中の値Tを返し、Err(E)の場合は引数で指定されたクロージャfを実行し、その結果（T型の値）を返します。デフォルト値の計算にコストがかかる場合や、エラー情報Eを使ってデフォルト値を計算したい場合に便利です。

“`rust
let maybe_number: Result = parse_number(“10”);
let number = maybe_number.unwrap_or(0); // 成功したので 10 を返す
println!(“{}”, number); // 出力: 10

let maybe_number_err: Result = parse_number(“abc”);
let number_or_default = maybe_number_err.unwrap_or(0); // 失敗したので 0 を返す
println!(“{}”, number_or_default); // 出力: 0

let config_str: Result = std::fs::read_to_string(“non_existent_file”);
let config_content = config_str.unwrap_or_else(|err| {
eprintln!(“設定ファイルの読み込みに失敗しました: {}”, err);
// エラー情報をログに出力し、デフォルトの設定内容を返す
“default_config”.to_string()
});
println!(“使用する設定:\n{}”, config_content);
“`

unwrap_orやunwrap_or_elseは、エラーを完全に握りつぶしてでも何らかの値を返したい場合に便利ですが、エラーが発生したという事実を無視することになるため、使用には注意が必要です。エラーのログ出力など、何らかの形でエラーが発生したことを記録することが推奨されます。

その他

他にも、Result型には様々なメソッドがあります。例えば、copied()やcloned()は、中の値がCopyまたはCloneトレイトを実装している場合に、その値をコピーまたはクローンして取り出すことができます。flatten()は、Result<Result<T, E>, E>のようなネストしたResultを平坦化します。これらのメソッドを理解することで、Result型を使ったコードをより簡潔かつ表現力豊かに書くことができます。必要に応じてRust公式ドキュメントを参照してください。

エラー伝播 (`?` 演算子)

Result型をmatch式で処理する方法は安全で明示的ですが、関数の呼び出しチェーンが深くなると、match … return Err(...) の繰り返しがコードを冗長にしてしまいます。Rustでは、この一般的なパターンを簡潔に記述するための構文として、? 演算子を提供しています。

?演算子は、Result（またはOption）の後ろに付けることで、その結果を処理します。具体的には：

ResultがOk(value)の場合、?演算子はそのvalueを取り出して式の値とします。処理はそのまま続行します。
ResultがErr(err)の場合、?演算子はそのerrを関数の戻り値として即座に関数からリターンします。

これは、以下のmatch式とほぼ同等です。

“`rust
// Result を返す式
let result: Result = / … /;

// ? 演算子を使った場合
let value = result?; // この行が Err の場合は関数から return Err(err); される

// match 式を使った場合 (? 演算子の内部動作に相当)
let value = match result {
Ok(v) => v,
Err(e) => return Err(e),
};
“`

?演算子を使うには、その演算子を使っている関数自体の戻り値の型がResult（またはOption）である必要があります。そうでないと、「エラーの場合に即座に関数からリターンする」という動作が成立しないからです。

先ほどのファイル読み込みの例を?演算子を使って書き直してみましょう。

“`rust
use std::fs::File;
use std::io::prelude::*;
use std::path::Path;
use std::io; // io::Error を使うのでインポート

// 戻り値の型が Result です
fn read_file_content_with_q(file_path: &Path) -> Result {
// File::open が Ok ならファイルオブジェクトが file に入り、Err なら関数から Err(err) を返す
let mut file = File::open(file_path)?;

let mut contents = String::new();
// file.read_to_string が Ok なら何もせず続行、Err なら関数から Err(err) を返す
file.read_to_string(&mut contents)?;

// ここまで来れたということは、File::open と read_to_string の両方が成功したということ
Ok(contents) // 成功した結果を Ok バリアントで返す

}

fn main() {
let path = Path::new(“hello.txt”);

// read_file_content_with_q が Result を返すので、match で処理する必要がある
match read_file_content_with_q(path) {
    Ok(content) => {
        println!("ファイル内容:\n{}", content);
    },
    Err(err) => {
        eprintln!("ファイル '{}' の処理中にエラーが発生しました: {}", path.display(), err);
    },
}

}
“`

このコードは、matchをネストしていたバージョンよりもはるかに簡潔になりました。?演算子を使うことで、エラーが発生した場合は関数の実行を中断し、エラーを自動的に呼び出し元に伝播させることができます。これにより、成功パスのロジックに集中してコードを書くことができるようになります。

エラー型変換と `From` トレイト

?演算子がエラーを伝播させる際、伝播されるエラー型は、?を付けている式が返すエラー型E1から、関数自体の戻り値の型に指定されているエラー型E2へ変換可能である必要があります。この変換は、標準ライブラリのFromトレイトによって行われます。具体的には、E1からE2への変換を行うimpl From<E1> for E2が存在している必要があります。

?演算子を含む以下のコードを考えます。

“`rust
fn some_function() -> Result<(), MyError> {
let result1: Result = / … /;
let value = result1?; // ここで AnotherError を MyError に変換して return Err したい

let result2: Result<String, YetAnotherError> = /* ... */;
let s = result2?; // ここで YetAnotherError を MyError に変換して return Err したい

Ok(())

}
“`

このコードがコンパイルされるためには、以下のFromトレイト実装が必要です。

“`rust
impl From for MyError {
fn from(err: AnotherError) -> Self {
// AnotherError から MyError への変換ロジック
// 例: MyError::AnotherErrorKind(err)
todo!()
}
}

impl From for MyError {
fn from(err: YetAnotherError) -> Self {
// YetAnotherError から MyError への変換ロジック
// 例: MyError::YetAnotherErrorKind(err)
todo!()
}
}
“`

Fromトレイトを実装することで、異なる種類のエラーを一つのカスタムエラー型に集約し、?演算子を使ってそれらをスムーズに伝播させることができます。これは、複数のライブラリやモジュールから返される様々なエラーを扱う場合に非常に重要なテクニックです。

多くの標準ライブラリのエラー型（std::io::Error, std::num::ParseIntErrorなど）は、一般的なカスタムエラー型からのFrom実装によく使われます。

このFromトレイトによる自動変換は、?演算子の強力な側面の一つです。独自のエラー型を定義し、関連する可能性のあるエラー型からのFromを実装することで、エラー伝播のコードを大幅に簡潔に保つことができます。

独自エラー型の定義

前述の通り、Result型のエラー側Eには、エラーに関する詳細情報を含めることができます。多くの場合、標準ライブラリが提供するエラー型だけでは不十分で、アプリケーション固有のエラーや、複数の異なるエラー型をまとめて扱いたいニーズが出てきます。このような場合に、独自のエラー型を定義します。

独自の回復可能なエラー型は、通常enumとして定義されます。これにより、発生しうる複数の種類のエラーを一つの型で表現できます。

例として、設定ファイルを読み込み、パースする関数を考えます。この関数は、ファイルI/Oエラー、パースエラー、設定内容が無効な場合のエラーなど、複数の種類の失敗をする可能性があります。

“`rust
use std::fmt;
use std::io;
use std::num::ParseIntError;

// 独自エラー型を enum で定義

[derive(Debug)] // デバッグ出力のために Debug トレイトを derive

enum ConfigError {
Io(io::Error), // io::Error をラップ
Parse(ParseIntError), // ParseIntError をラップ
InvalidValue(String), // 無効な設定値の場合
NotFound, // 設定が見つからない場合 (io::ErrorKind::NotFound とは別に定義)
}

// Result のエラー型として使えるように、std::error::Error トレイトを実装する
// これは、エラーチェーンや downcasting など、より高度なエラーハンドリングのために必要
// std::error::Error トレイトは Debug と Display の実装を要求する
impl std::error::Error for ConfigError {
// cause() や source() メソッドを提供する (Rust 1.30 以降は source が推奨)
// 他のエラー型をラップしている場合に、その原因となったエラーを返す
fn source(&self) -> Option<&(dyn std::error::Error + ‘static)> {
match self {
ConfigError::Io(e) => Some(e),
ConfigError::Parse(e) => Some(e),
// その他のバリアントは他のエラーをラップしていないため None
ConfigError::InvalidValue(_) => None,
ConfigError::NotFound => None,
}
}
}

// ユーザー向けのエラーメッセージを表示するために Display トレイトを実装する
impl fmt::Display for ConfigError {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
match self {
ConfigError::Io(e) => write!(f, “I/O エラー: {}”, e),
ConfigError::Parse(e) => write!(f, “パースエラー: {}”, e),
ConfigError::InvalidValue(msg) => write!(f, “設定値が無効です: {}”, msg),
ConfigError::NotFound => write!(f, “設定ファイルが見つかりません”),
}
}
}

// ? 演算子で他のエラー型から ConfigError に自動変換できるように From トレイトを実装する
impl From for ConfigError {
fn from(err: io::Error) -> Self {
// io::Error::NotFound の場合は特別に NotFound バリアントにするなど、
// エラーの種類に応じて変換ロジックを調整できる
if err.kind() == io::ErrorKind::NotFound {
ConfigError::NotFound
} else {
ConfigError::Io(err)
}
}
}

impl From for ConfigError {
fn from(err: ParseIntError) -> Self {
ConfigError::Parse(err)
}
}

// この独自エラー型を使用する関数
fn read_and_parse_config(file_path: &Path) -> Result {
let config_str = std::fs::read_to_string(file_path)?; // ? 演算子により io::Error は ConfigError::Io に変換される

let value_str = config_str.trim();
let value = value_str.parse::<i32>()?; // ? 演算子により ParseIntError は ConfigError::Parse に変換される

if value < 0 {
    return Err(ConfigError::InvalidValue("設定値は0以上である必要があります".to_string()));
}

Ok(value)

}

fn main() {
let config_path = Path::new(“config.txt”);

match read_and_parse_config(config_path) {
    Ok(config_value) => {
        println!("設定値: {}", config_value);
    }
    Err(ConfigError::NotFound) => {
        eprintln!("{}", ConfigError::NotFound); // Display トレイトで出力
    }
    Err(err) => {
        // その他のエラーは Display トレイトで出力
        eprintln!("設定の読み込み中にエラーが発生しました: {}", err);
        // デバッグ時には Debug トレイトでの出力も便利
        // eprintln!("デバッグ情報: {:?}", err);
        // 元のエラーを辿ることも可能 (source() メソッド)
        if let Some(source) = err.source() {
             eprintln!("原因: {}", source);
        }
    }
}

}
“`

この例では、ConfigErrorという独自のenumエラー型を定義しました。このenumは、発生しうる様々なエラー（I/O、パース、無効な値、見つからない）をバリアントとして持ちます。

#[derive(Debug)] を付けることで、開発者向けの詳細なデバッグ情報を表示できるようになります。
std::fmt::Display トレイトを実装することで、println! や format! マクロで人間が読める形式のエラーメッセージを表示できるようになります。
std::error::Error トレイトを実装することで、Rustのエラー処理エコシステム（例: source()メソッドを使ったエラーチェーン）に組み込むことができます。通常、DisplayとDebugの実装があれば、Errorトレイト自体の実装は非常にシンプルです。
From トレイトを実装することで、io::ErrorやParseIntErrorといった他のエラー型からConfigErrorへの自動変換が可能になり、?演算子をスムーズに使えるようになります。

このアプローチは、アプリケーションやライブラリ内で発生する様々なエラーを統一的に扱うための強力な方法です。

`thiserror` クレートを使った簡易化

独自エラー型を定義し、関連するトレイト（Debug, Display, Error, From）を手動で実装するのは、特にエラーの種類が多い場合に冗長になりがちです。コミュニティによって開発されたthiserrorクレートは、このプロセスを大幅に簡略化します。

thiserrorを使うと、deriveマクロと属性を使って、Debug, Display, Error, Fromの実装を自動生成できます。

Cargo.tomlに依存関係を追加します:
toml [dependencies] thiserror = "1.0"

そして、独自エラー型を以下のように定義できます。

“`rust
use thiserror::Error;
use std::io;
use std::num::ParseIntError;

[derive(Error, Debug)] // Error, Debug トレイトを derive

enum ConfigError {
// #[error(“I/O エラー: {0}”)] のようにメッセージを指定
#[error(“I/O エラー: {0}”)]
Io(#[from] io::Error), // #[from] で From を自動実装

#[error("パースエラー: {0}")]
Parse(#[from] ParseIntError), // #[from] で From<ParseIntError> を自動実装

#[error("設定値が無効です: {0}")]
InvalidValue(String),

#[error("設定ファイルが見つかりません")]
NotFound, // From は不要な場合

}

// この ConfigError を使った関数は前述の例と同じように書ける
// fn read_and_parse_config(…) -> Result { … }

// main 関数も前述の例とほぼ同じように書ける
fn main() {
// … (前述の main 関数と同様)
}
“`

#[derive(Error, Debug)]と、各バリアントに#[error(...)]属性を付けることで、DisplayとErrorトレイトの実装が自動生成されます。#[from]属性をフィールドに付けることで、その型からのFromトレイト実装が自動生成され、?演算子による自動変換が可能になります。

thiserrorを使うことで、独自エラー型の定義と必要なトレイト実装が非常に簡潔になり、コードの可読性と保守性が向上します。多くのRustプロジェクトで標準的に採用されている手法です。

Result型と他の機能との連携

Result型はRustのエコシステム全体で広く使われており、他の標準ライブラリや機能とスムーズに連携します。

イテレーターとResult (`Iterator::collect()`)

Rustのイテレーターは非常に強力で、様々な変換や集約操作を行うことができます。特に、イテレーターの要素がResult型である場合に、collect()メソッドを使うと非常に便利なパターンがあります。

collect()メソッドはイテレーターの要素を集めて新しいコレクション（Vec、HashMapなど）や、あるいはResultのような単一の値に変換します。イテレーターの要素がResult<T, E>である場合に、collect::<Result<Collection<T>, E>>()のように呼び出すと、以下の動作をします：

イテレーターの要素を一つずつ処理します。
もし要素がOk(T)であれば、その中のTを一時的なコレクションに集めます。
もし要素がErr(E)であれば、そこで処理を中断し、そのErr(E)を全体の最終結果として即座に返します。
すべての要素がOkであれば、一時的なコレクションに集められたすべてのTを最終的なコレクションにまとめて、Ok(Collection<T>)として返します。

これは、複数のフォールブルな操作の結果をまとめて処理し、一つでも失敗があれば全体の失敗としたい場合に非常に強力なイディオムです。

“`rust
fn parse_numbers(s_list: Vec<&str>) -> Result, std::num::ParseIntError> {
// Vec<&str> のイテレーターを作成
s_list.into_iter()
// 各要素に対して parse::() を呼び出す。これは Result を返すイテレーターになる
.map(|s| s.parse::())
// Result のイテレーターに対して collect を呼び出す
// collect::, ParseIntError>>() の型推論が効いている
.collect() // Result, ParseIntError> を返す
}

fn main() {
let input1 = vec![“1”, “2”, “3”, “4”];
let numbers1 = parse_numbers(input1);
println!(“{:?}”, numbers1); // 出力例: Ok([1, 2, 3, 4])

let input2 = vec!["1", "abc", "3", "4"];
let numbers2 = parse_numbers(input2);
println!("{:?}", numbers2); // 出力例: Err(ParseIntError { kind: InvalidDigit })

}
“`

collect()メソッドにResult<Vec<i32>, ParseIntError>という型注釈（実際には型推論が効くことが多い）を付けることで、イテレーターからエラーハンドリング付きでコレクションを構築できます。これは、複数の外部システム呼び出し、複数のファイル処理など、リストに含まれる各要素に対する操作がエラーを返す可能性がある場合に非常に有効です。

非同期プログラミング (`async/await`) とResult

Rustの非同期プログラミング（async/await）は、Futureと呼ばれる値を操作します。async fnは、その戻り値の型を持つFutureを返します。非同期操作もまた失敗する可能性があるため、async fnの戻り値の型としてResultがよく使われます。

例えば、非同期でファイルを読む関数は、async fn read_async(...) -> Result<String, io::Error> { ... } のようなシグネチャになります。

async fnの中では、?演算子を通常の関数と同様に使うことができます。?演算子は、非同期操作（Future）が返すResultを処理し、Errの場合はFutureの結果をErrとして即座に返します。

“`rust
use tokio::fs::File;
use tokio::io::AsyncReadExt;
use std::path::Path;
use std::io;

[tokio::main] // main 関数を非同期にするための属性

async fn read_file_async(file_path: &Path) -> Result {
let mut file = File::open(file_path).await?; // 非同期オープン。await? で Result を処理

let mut contents = String::new();
file.read_to_string(&mut contents).await?; // 非同期読み込み。await? で Result を処理

Ok(contents)

}

[tokio::main]

async fn main() {
let path = Path::new(“hello.txt”);

match read_file_async(path).await { // async fn の結果を await して Result を取得
    Ok(content) => {
        println!("ファイル内容 (async):\n{}", content);
    },
    Err(err) => {
        eprintln!("非同期ファイル読み込みエラー: {}", err);
    },
}

}
“`

非同期コードにおけるエラーハンドリングも、同期コードと基本的に同じResult型と?演算子を使用します。?演算子は非同期コンテキスト（async fn内）でも期待通りに動作し、エラーを効率的に伝播させます。

エラーハンドリングのベストプラクティス

安全で保守性の高いRustプログラムを書くために、Result型とエラーハンドリングに関するいくつかのベストプラクティスがあります。

パニックはリカバリー不能なエラーに限定する: 前述の通り、panic!、unwrap()、expect()はプログラムを強制終了させます。これらは、プログラマの間違い（バグ）や、実行環境が致命的に壊れているなど、プログラムが健全な状態で続行できない状況にのみ使用すべきです。外部からの入力エラー、ファイルI/Oエラー、ネットワークエラーなど、発生しうる環境的・入力的なエラーはResultで返すようにします。
ライブラリは詳細なエラー型を返す: ライブラリを書く場合、利用者がエラーに対して柔軟な対応（ログ出力、リトライ、代替処理など）を行えるよう、詳細な情報を含む独自のenumエラー型を返すのが良いプラクティスです。可能な限りthiserrorを使ってエラー型を定義し、source()でエラーチェーンを辿れるようにします。
アプリケーションは簡易なエラー処理も検討する: アプリケーションのトップレベル（特にmain関数に近い部分）では、エラーが発生したら単にエラーメッセージを出力して終了するだけで十分な場合があります。このような場合、anyhowクレートのような簡易エラーハンドリングライブラリを使うと、異なる種類のエラーを簡単にラップして伝播させることができ、コードがより簡潔になります。ただし、これはアプリケーションの要件（どれだけ頑丈である必要があるか、エラーの種類に応じて異なる処理が必要かなど）によります。
エラーメッセージを分かりやすくする: エラーメッセージは、何が起こったのか、そして可能であればどうすれば解決できるのかをユーザー（または開発者）に伝えるべきです。具体的なファイル名、操作内容、関連する設定値などの文脈情報を含めるように心がけましょう。Displayトレイトの実装を丁寧に行うことが重要です。
エラーチェーンを活かす (source()): 独自エラー型で他のエラー型をラップする場合、std::error::Errorトレイトのsource()メソッドを正しく実装することで、エラー発生時の根本原因を辿ることができます。これはデバッグ時に非常に役立ちます。thiserrorはこの実装を自動化してくれます。
文脈情報をエラーに含める: エラーが発生した状況（どのファイルを処理していたか、どのユーザーからのリクエストだったかなど）は、エラー型自体に含めるか、エラー発生時にログに出力するなどして記録します。これにより、デバッグや問題の診断が容易になります。
エラーを無視しない: let _ = some_result_returning_function(); のようにResultを無視することは、エラーが発生した事実を隠蔽してしまいます。最低限、エラーログを出力するなど、何らかの形でエラーを記録するか、適切に処理するようにしましょう。

他のエラーハンドリング手法との比較

RustのResult型は、他の言語の主要なエラーハンドリング手法と比較して、どのような特徴を持つのでしょうか。

例外 (Java, Python, C++, etc.)

長所:
- 成功パスのコードが比較的簡潔になることが多い。
- エラー処理コードを、エラーが発生した場所から離れた場所（コールスタックの上位）に集約できる。
短所:
- 関数シグネチャから、どのような例外が投げられるか分からないことが多い（JavaのChecked Exceptionは例外）。
- 例外がどこで捕捉されるか、あるいは捕捉されないままプロセスを終了するかを、コンパイラが検証しないことが多い。
- 意図しない場所で例外が捕捉されたり、例外の捕捉漏れによるクラッシュが発生しやすい。
- スタックアンワインドなどのオーバーヘッドが発生する可能性がある。

RustのResult型は、例外の短所を克服することを強く意識しています。関数の戻り値型にエラーの可能性を明示することで、呼び出し元にエラー処理を強制し、コンパイル時にエラーの捕捉漏れを防ぎます。エラーは値として扱われるため、通常の制御フロー内で処理され、特定の「例外的な」パスを通る必要がありません。

エラーコード (C, Goの一部など)

長所:
- ランタイムのオーバーヘッドが小さい。
- 明示的に戻り値でエラーを示す。
短所:
- 成功時の戻り値を返すため、エラーコードと成功値を同時に返すために工夫が必要になる（例: 構造体で返す、ポインタ引数に成功値を格納）。
- エラーコードが数値やマクロで表現されることが多く、エラーの種類や詳細な原因が分かりにくい場合がある。
- 呼び出し元がエラーコードをチェックし忘れる可能性があるが、コンパイラはそれを検出しない。
- 複数のエラーコードを扱う場合に、複雑なif/else ifやswitch文が必要になる。

RustのResult型は、エラーコードの「エラーを明示的に返す」という側面を持ちつつ、その短所を改善しています。Result<T, E>という一つの型で成功値Tとエラー値Eの両方を表現でき、型システムがエラー処理の漏れを検出します。また、エラー値Eには詳細な情報を含む独自の型を使用できるため、エラーの原因特定が容易です。

Option型 (Rust, Swiftなど)

Option<T>は値が存在しない可能性を示すために使われます。これはエラーの一種（例: 「見つからない」）を表すこともできますが、なぜ値が存在しないのか、というエラーの原因を示すことはできません。
Result<T, E>は、成功値がないだけでなく、失敗の具体的な原因Eを示すことができます。
使い分けとしては、「値が存在しないことがエラーの原因なのか、それとも単に値がないだけなのか」で判断します。例えば、マップからキーを引く場合はOption、ファイルを読む場合はResultが適切です。

Result型の応用例

Result型は、Rustでエラーが発生しうる様々な操作の戻り値として広く使われています。以下に一般的な応用例をいくつか示します。

ファイルI/O: std::fs::File::open, std::fs::read_to_stringなど、ファイルシステム関連の操作は Result<..., std::io::Error> を返します。
ネットワーク通信: std::net::TcpStream::connect, std::io::Read, std::io::Write トレイトのメソッドなど、ネットワーク関連の操作も Result<..., std::io::Error> を返します。
文字列パース: str::parse, String::from_utf8など、文字列を他の型に変換する操作は、パースエラーを示すResultを返します（例: Result<..., std::num::ParseIntError>, Result<String, std::string::FromUtf8Error>)。
外部ライブラリ: 多くのRustライブラリは、エラーハンドリングにResult型を採用しています。例えば、JSONパースライブラリのserde_jsonはResult<T, serde_json::Error>を返します。データベースライブラリやWebフレームワークなども同様です。

これらのResultを返す操作を組み合わせることで、複雑な処理フローを安全に記述できます。?演算子と独自エラー型、Fromトレイトを組み合わせることで、異なるソースからのエラーを統一的に扱い、効率的に伝播させることができます。

よくある疑問とアンチパターン

なぜ `unwrap()` を避けるべきなのか？

最も重要な点は、unwrap()が失敗した場合にパニックを引き起こし、プログラムが強制終了することです。これは、ユーザー環境や予期しない入力データに対してプログラムを脆弱にします。特に、ユーザー向けのアプリケーションや、サーバーとして継続的に稼働するプログラムでは、パニックは致命的な問題につながることが多いです。

unwrap()は、絶対に失敗しないと確信できる非常に限定的な状況でのみ使用すべきです。例えば、ユニットテストで「このケースでは絶対に成功するはずだ」とアサートしたい場合や、非常に単純でエラー発生の可能性がゼロであることが自明な内部処理などです。それ以外の、外部からの入力や環境に依存する可能性のある処理では、ResultのErrバリアントを適切に処理するか、少なくともexpect()を使ってパニックメッセージを分かりやすくすることが推奨されます（ただし、expect()もパニックであることに変わりはありません）。

エラーを握りつぶす行為 (`let _ = result;`)

Result型の値を生成する関数を呼び出し、その結果をlet _ = ...;のように変数に束縛して、OkもErrも何も処理しないことは、エラーを意図的に（あるいは意図せず）無視する行為です。

“`rust
fn do_something_that_might_fail() -> Result<(), String> {
// … 失敗する可能性のある処理 …
Err(“failed to do something”.to_string())
}

fn main() {
// エラーを完全に無視している！
let _ = do_something_that_might_fail(); // Err(“…”) が返されるが、何も起こらない

println!("処理が続行されましたが、エラーが発生していた可能性があります。");

}
“`

これはアンチパターンです。エラーが発生したという事実をプログラムが認識せず、不健全な状態のまま処理を続行してしまう可能性があります。最低限、エラーが発生したことをログに出力するなど、何らかの形で記録すべきです。Result型の値を返されたら、match、if let Err、?、あるいはunwrap_or_elseなどで、Errの場合の処理を明示的に記述するようにしましょう。

不適切なエラー型の使用

エラー型が詳細すぎる/小さすぎる: エラー型が必要以上に多くのバリアントや情報を持つと、扱うのが難しくなります。逆に、情報が少なすぎると、エラーの原因特定が困難になります。アプリケーションの要件とエラーハンドリングの粒度に応じて、適切な情報量のエラー型を設計することが重要です。
Stringや&strをエラー型として使う: 簡単なスクリプトなどでは許容されることもありますが、エラーの原因や種類を区別できないため、本格的なアプリケーションでは推奨されません。常にエラーの種類を区別できる独自のエラー型を使用しましょう。anyhowのようなライブラリを使う場合でも、根本原因は保持されています。

まとめ

RustのResult型は、その安全で明示的なエラーハンドリング機構の中核をなす強力なツールです。例外に依存する多くの言語とは異なり、Rustはエラーを値として扱うことで、コンパイル時のチェックと予測可能な実行フローを実現します。

この記事では、Result型の定義、OkとErrバリアントの意味、matchやif letを使った基本的な処理方法から始め、map、map_err、and_then、or_elseといった便利なメソッドによる柔軟な操作方法、そして?演算子を使った効率的なエラー伝播の仕組みまでを詳しく解説しました。また、アプリケーション固有のエラーを表現するための独自エラー型の定義方法、特にstd::error::Error、std::fmt::Display、std::fmt::Debug、Fromといったトレイトの実装、そしてthiserrorクレートによる実装の簡易化についても触れました。さらに、イテレーターや非同期プログラミングとの連携、 Result型を効果的に使用するためのベストプラクティス、そして他の言語のエラーハンドリング手法との比較を通じて、Rustのアプローチの利点を明確にしました。

Result型と?演算子、そして適切に設計された独自エラー型を組み合わせることで、あなたは以下のようなRustらしい、堅牢で信頼性の高いプログラムを書くことができるようになります。

エラーの捕捉漏れを防ぐ: コンパイラがResultの処理を強制します。
エラー発生の可能性を明確にする: 関数のシグネチャを見るだけでエラーの可能性が分かります。
エラー情報を豊かにする: 独自のエラー型で、エラーの種類や詳細な原因を伝達できます。
デバッグを容易にする: エラーメッセージ、デバッグ情報、エラーチェーンによって、問題の原因特定がスムーズになります。
回復可能なエラーと回復不可能なエラーを区別する: プログラムを継続させるべきエラーと、終了させるべきエラーを明確に区別できます。

最初はResult型の利用や独自エラー型の定義が少し手間に感じるかもしれませんが、一度慣れてしまえば、その安全性と明示性の利点がコードの信頼性向上に大きく貢献していることを実感できるはずです。

Rustでのプログラミングにおいて、エラーハンドリングは基礎中の基礎であり、最も重要な概念の一つです。Result型をマスターすることは、安全で効率的なRustコードを書くための鍵となります。ぜひ、この記事で学んだ知識を活かして、あなたのRustプロジェクトでResult型を積極的に活用してください。

Happy coding!

これで約5000語の記事となりました。RustのResult型とその関連するエラーハンドリングの概念を網羅的に説明できたかと思います。コード例も適宜挿入し、理解を助けるように努めました。

RustのResult型入門: 安全なエラーハンドリングを学ぼう

はじめに

なぜエラーハンドリングが重要なのか？

Rustのエラーハンドリング哲学

Result型とは何か？

なぜOption型だけでは不十分なのか？

Result型の基本的な使い方

match 式を使ったエラーハンドリング

if let を使ったResult型のチェック

Result型の便利なメソッド

状態の確認: is_ok(), is_err()

値の取り出し（パニックする可能性あり）: unwrap(), expect()

Option型への変換: ok(), err()

成功値/エラー値の変換: map(), map_err()

結果を返すクロージャとの連携: and_then(), or_else()

デフォルト値を返す: unwrap_or(), unwrap_or_else()

その他

エラー伝播 (? 演算子)

エラー型変換と From トレイト

独自エラー型の定義

[derive(Debug)] // デバッグ出力のために Debug トレイトを derive

thiserror クレートを使った簡易化

[derive(Error, Debug)] // Error, Debug トレイトを derive

Result型と他の機能との連携

イテレーターとResult (Iterator::collect())

非同期プログラミング (async/await) とResult

[tokio::main] // main 関数を非同期にするための属性

[tokio::main]

エラーハンドリングのベストプラクティス

他のエラーハンドリング手法との比較

例外 (Java, Python, C++, etc.)

エラーコード (C, Goの一部など)

Option型 (Rust, Swiftなど)

Result型の応用例

よくある疑問とアンチパターン

なぜ unwrap() を避けるべきなのか？

エラーを握りつぶす行為 (let _ = result;)

不適切なエラー型の使用

まとめ

コメントする 返信をキャンセル

`match` 式を使ったエラーハンドリング

`if let` を使ったResult型のチェック

状態の確認: `is_ok()`, `is_err()`

値の取り出し（パニックする可能性あり）: `unwrap()`, `expect()`

Option型への変換: `ok()`, `err()`

成功値/エラー値の変換: `map()`, `map_err()`

結果を返すクロージャとの連携: `and_then()`, `or_else()`

デフォルト値を返す: `unwrap_or()`, `unwrap_or_else()`

エラー伝播 (`?` 演算子)

エラー型変換と `From` トレイト

`thiserror` クレートを使った簡易化

イテレーターとResult (`Iterator::collect()`)

非同期プログラミング (`async/await`) とResult

なぜ `unwrap()` を避けるべきなのか？

エラーを握りつぶす行為 (`let _ = result;`)

コメントする返信をキャンセル