rust resultを理解する: エラー処理の基本と実務に役立つ活用例

プログラミング言語•2025/1/24

はじめに

皆さんはRustのプログラムを書いていて、エラー処理をどう扱うか悩んだことはないでしょうか。 RustにはResultという型が用意されており、これを使うとエラー処理を明確に表現できます。ただ、新しく学び始めた方にとっては、OkやErrなどの用語が少し難しく感じることがあるかもしれません。ですが、使い方をしっかり理解すると、コードの可読性や安全性を保ちやすくなります。

この記事では、rust resultの基本概念から実務における活用シーンまでを説明していきます。初めてRustを触る皆さんも、実務でエラー処理をどう扱うか知りたい方も、ぜひ最後まで読んでみてください。

Result型とは何か

Result型は、処理結果として「成功した場合」と「失敗した場合」を明確に区別して返せる型です。 Rustの標準ライブラリに定義されており、以下のように2つの値を持つことでエラー処理を表現します。

Ok : 処理が成功した場合に返る値
Err : 処理が失敗した場合に返る値

たとえばファイル操作やネットワーク通信など、失敗の可能性がある処理ではResult型がよく使われます。こうすることで、失敗時に曖昧な値が返ってくることを防ぎ、具体的にどういうエラーが起こったかをコードで扱いやすくしています。

なぜResult型が必要なのか

エラー処理において、例外機構を使う言語も少なくありません。しかしRustでは、言語仕様として例外を多用せず、Result型でエラーを返す手法を推奨しています。これは、エラーが起きた場合に「何が失敗しているのか」をコンパイル時にも意識できるためです。

一方で、Result型を使うとコードの分岐が増えると感じることがあるかもしれません。ただ、その分だけ「エラーが起きる可能性」を明確に記述できるのが大きなメリットです。また、呼び出し元でもエラーをどう扱うかが見えやすくなるため、大規模開発でもトラブルが起こりにくくなります。

基本的な使い方

まずは簡単なコード例を見てみましょう。ここではファイルを読み込み、内容を文字列として返す関数を想定します。


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

fn read_file_content(path: &str) -> Result<String, io::Error> {
    let mut file = File::open(path)?; // エラーがあればここで返る
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    Ok(contents)
}

fn main() {
    match read_file_content("example.txt") {
        Ok(text) => println!("読み込んだ内容: {}", text),
        Err(e) => eprintln!("エラーが発生しました: {:?}", e),
    }
}

read_file_content関数では、Result String, io::Error が返り値になっています。成功したときは文字列が入ったOkを返し、失敗したときはErrを返します。 ?演算子を使うと、エラーが起きたタイミングで早期に処理を終了しつつ、エラー情報を呼び出し元に伝えられます。

?演算子の役割

Rustにおけるエラー処理を簡潔にするのが**?**演算子です。 Result型を返す関数の中で?を使うと、Errが返された瞬間にその関数の処理を終了して、呼び出し元にErrをそのまま渡します。 Okならば結果をアンラップして後続の処理へ進みます。

この演算子があることで、matchブロックを書かなくてもエラーを伝搬できるので、コードが読みやすくなります。ただし、関数の戻り値がResult型など「エラーを返せる型」になっている必要があるので、呼び出し先の型をきちんと確認しながら使うとよいでしょう。

実務との関係

Rustのエラー処理は、システムプログラミングだけでなく、Webサーバー開発やCLIツールの作成など幅広い場面で利用されています。たとえば以下のようなケースでResult型が活躍します。

ネットワーク通信でのステータスコードチェック
ファイルの読み書きや削除操作
データベースへのアクセスやクエリ実行
JSONやXMLのパース

失敗する可能性を明示的に示すことで、バグを事前に発見しやすいメリットがあります。コードレビューの際もエラー処理が抜け落ちていないかが分かりやすく、保守性が高いコードを目指しやすくなります。

match式によるハンドリング

?演算子を使わず、もう少し手動でエラーを扱いたい場合はmatch式が有効です。たとえば、エラーの内容に応じて異なるログを出したり、処理を分岐したい場合などに便利です。


fn handle_result(value: Result<i32, String>) {
    match value {
        Ok(num) => println!("成功しました。値は: {}", num),
        Err(msg) => {
            if msg.contains("not found") {
                println!("ファイルが見つかりませんでした。メッセージ: {}", msg);
            } else {
                println!("その他のエラーが発生しました: {}", msg);
            }
        }
    }
}

fn main() {
    handle_result(Ok(10));
    handle_result(Err("File not found".to_string()));
}

ここでResult<i32, String>の形を取っていますが、実務ではエラー型として独自に定義したエラー列挙型や、標準ライブラリのエラー型を使うことが多いです。 matchを使えば、エラーごとに対策を変えたいケースでも柔軟に対応できます。

メソッドチェーンでの活用

Result型には、エラーを扱いやすくするさまざまなメソッドが備わっています。たとえばmapやand_thenなどが代表的です。


fn add_one_if_ok(value: Result<i32, &'static str>) -> Result<i32, &'static str> {
    value.map(|num| num + 1)
}

fn chain_example(value: Result<i32, &'static str>) -> Result<String, &'static str> {
    value
        .map(|num| num * 2)
        .map(|num| format!("最終結果: {}", num))
}

map : Okの値を別の値に変換し、ErrならそのままErrを返す
and_then : Okの値を受け取り、結果として新たなResultを返す関数を呼び出す

これらを組み合わせると、エラー処理の分岐を適度にまとめつつ、成功時の処理をチェーンのようにつなげられます。コードが読みやすくなり、拡張もしやすくなるため、実務でもよく使われます。

具体的な活用シーン一覧

Result型を使ったエラー処理は、以下のような場面でよく登場します。「どんなシーンで役立つのか」が分かるように、簡単な一覧を用意しました。

シーン	内容
ファイル操作	ファイルが存在しない・権限がないなど
ネットワーク通信	接続失敗、タイムアウト、ステータスエラー
データベースアクセス	接続エラー、クエリエラー
シリアライズ/デシリアライズ	JSONやXMLのパースエラーなど
API呼び出し	外部APIからのエラー応答

このようにResult型はあらゆるエラーに対応するための仕組みとして使えます。初心者の皆さんも、具体的にどこでエラーが発生しそうかを想像しながらコードに組み込むと理解が進みやすいでしょう。

大規模開発でのメリット

小規模なスクリプトでは、エラー処理をあまり意識せずに書いてしまうこともあるかもしれません。しかし、大規模開発になるほどResult型でのエラー処理は効果が表れます。

エラーの型が厳密になるため、想定外のエラーを防ぎやすい
検討不足のエラーケースをコンパイラが警告してくれる
呼び出し元がエラーの扱い方を明確に選択できる

チーム開発では、エラー処理を統一ルールに沿って書くと、コードレビュー時にもチェックが簡単になります。また、エラー時のログや通知に対して素早く対処できる体制が整うでしょう。

複数のプロジェクトで異なるRustのバージョンを使う場合は、同じResult型周りのメソッドでも挙動が変わる可能性があります。そのため、チーム内で事前にバージョンを合わせるか、互換性を確認しながら開発すると良いです。

カスタムエラー型との組み合わせ

標準ライブラリのエラー型だけでなく、自作のエラー型をResult型のErrとして扱う例も多いです。たとえば複数のモジュールが異なるエラーを返す場合は、統合されたエラー列挙型を用意することがあります。


#[derive(Debug)]
enum MyError {
    Io(std::io::Error),
    Parse(std::num::ParseIntError),
    Custom(String),
}

fn parse_number(s: &str) -> Result<i32, MyError> {
    let num = s.parse::<i32>().map_err(MyError::Parse)?;
    Ok(num)
}

ここではMyErrorという独自の列挙型を作り、IoやParseなど複数のエラーを持てるようにしています。これにより、呼び出し元ではどの種類のエラーが起きたかを明確に判断できるようになります。

よくある疑問やつまずき

Result型を使うときに、初心者の皆さんが抱えそうな疑問をいくつか挙げます。

エラーをどうやってユーザーに伝えるのか

→ CLIであれば標準エラー出力に表示する、Webならログに記録するなどが基本です。

複数のエラーが混在すると混乱しないか

→ カスタムエラー型を定義し、モジュールごとに分割すると整理しやすくなります。

例外処理のほうが楽なのでは

→ Rustはコンパイル時にエラー可能性を認識できる利点があり、予期せぬエラーを防ぎやすい設計になっています。

これらの疑問は、実際に小さなサンプルコードを書きながら試してみると解消しやすいものが多いです。コードを書きながら、Errが返ってきたときに自分の処理がどう反応するかを確かめてみると理解が深まるでしょう。

エラー処理を厳密に行うか、または簡易的に行うかはプロジェクトの要件次第です。小さなツールならエラー内容をシンプルに表示するだけで良いことも多いです。

まとめ

ここまで、rust resultの基本的な仕組みと実務での使い方について見てきました。 Result型を利用することで、コードの可読性や保守性を高めつつ、エラー処理を明示的に扱えます。特に大規模開発でエラー管理をきちんと行うためには、Result型とカスタムエラーの組み合わせがよく使われます。

最初はコード内でOkやErrが出てくると戸惑うかもしれませんが、Rustのコンパイラはヒントを出してくれるため、少しずつ慣れていけば問題ありません。皆さんも実際にコードを書きながら、Result型をどのように使えばよいか試してみてはいかがでしょうか。これからRustを学ぶ方にとって、エラー処理は大切な要素の一つですので、ぜひ活用を検討してみてください。