문서가격블로그
문의하기
로그인무료로 가입하기
Back to Tech Articles

Rust Webサービスにおける基本的な結果処理から堅牢なエラー管理へ

9월 02, 2025
# Misc

Daniel Hayes

Full-Stack Engineer · Leapcell

이 게시물은 English, 한국어 및 Deutsch에서도 볼 수 있습니다.
Cover of "Rust Webサービスにおける基本的な結果処理から堅牢なエラー管理へ"

はじめに

Rustの世界では、堅牢性と信頼性が最重要視されます。Webサービスを構築する際、エラーを適切に処理することは、単なるベストプラクティスではなく、安定したユーザーフレンドリーなアプリケーションを作成するための必要不可欠な要素です。開発者はしばしば、成功（Ok）または失敗（Err）を表す強力なenumであるRustのResult型から学習を始めます。これは多くのシナリオで完全に適切ですが、Webサービスが複雑になるにつれて、汎用的なエラー型や基本的なStringエラーにのみ依存することは、コードの絡み合い、デバッグの困難さ、そしてクライアントに意味のある応答を提供できないことにつながる可能性があります。この記事では、シンプルなResult処理から、カスタムエラー型の作成、そして最終的にはIntoResponseトレイトを使用してこれらのカスタムエラーをWebフレームワークと統合することで、APIが成功と失敗の両方の言語を明瞭かつ表現力豊かに話せるようにする旅に出かけます。

コアコンセプト

実装の詳細に入る前に、Rustにおける堅牢なエラー管理の基盤となるコアコンセプトについて共通の理解を確立しましょう。

  • Result<T, E>: Rustの標準ライブラリにある、成功する可能性のある計算を表すenum。Tは成功時の値の型、Eはエラー値の型です。この型は、開発者に潜在的な失敗を明示的に処理することを強制し、これはRustの安全性の要です。
  • Errorトレイト: Rustの標準ライブラリにおける、エラーを表す型の基本的なトレイト。このトレイトを実装することで、カスタムエラー型は?演算子による伝播や、エラーレポートライブラリなどの他のエラー処理メカニズムと相互運用できるようになります。これにはDebugとDisplayの実装、およびエラーの連鎖のためのオプションのsourceメソッドの実装が必要です。
  • From<T> for Eトレイト: ある型Tから別の型Eへの不変の型変換を可能にするトレイト。エラー処理では、より具体的なエラー型を、より汎用的なカスタムエラーenumに変換するために頻繁に使用され、エラー伝播を容易にします。
  • IntoResponseトレイト（Webフレームワーク）: 多くのRust Webフレームワーク（例: Axum、Actix Web、Rocket）は、カスタム型をHTTPレスポンスに変換できるIntoResponseという名前のトレイト、またはそれに類するものを備えています。これは、カスタムエラー型がHTTPステータスコード、ヘッダー、およびクライアントに返されるボディを直接決定できるようにするため、エラー処理に不可欠です。

シンプルなResultからカスタムエラーへ

IDでユーザーを取得するシンプルなAPIエンドポイントを構築していると想像してみましょう。最初は、Stringエラーを持つ基本的なResultを使用するかもしれません。

// Basic Result handling
async fn get_user_simple(user_id: u32) -> Result<String, String> {
    if user_id % 2 == 0 {
        Ok(format!("User {user_id} found!"))
    } else {
        Err("User not found".to_string())
    }
}

これは機能しますが、Stringエラーには構造が欠けています。アプリケーションが成長するにつれて、「ユーザーが見つかりません」と「データベース接続に失敗しました」というエラーを、単なる文字列に基づいて区別することは脆弱になります。ここでカスタムエラー型が輝きます。

カスタムエラーenumの実装

区別されたエラー条件を列挙するenumを定義できます。このenumを?で伝播可能でフォーマット可能な適切なエラー型にするために、Debug、Display、そしてErrorトレイトを実装します。

use std::fmt::{Display, Formatter};
use std::error::Error;

#[derive(Debug)]
pub enum AppError {
    UserNotFound(u32),
    DatabaseError(String),
    IOError(std::io::Error),
    InvalidInput(String),
    // より具体的なエラーをここに追加できます
}

impl Display for AppError {
    fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
        match self {
            AppError::UserNotFound(id) => write!(f, "User with ID {id} was not found."),
            AppError::DatabaseError(msg) => write!(f, "Database error: {}", msg),
            AppError::IOError(err) => write!(f, "IO error: {}", err),
            AppError::InvalidInput(msg) => write!(f, "Invalid input: {}", msg),
        }
    }
}

impl Error for AppError {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        match self {
            AppError::IOError(err) => Some(err),
            _ => None,
        }
    }
}

// サービス関数での使用例
async fn get_user_complex(user_id: u32) -> Result<String, AppError> {
    if user_id == 0 {
        return Err(AppError::InvalidInput("User ID cannot be zero".to_string()));
    }
    match fetch_user_from_db(user_id).await {
        Ok(user_data) => Ok(user_data),
        Err(db_err) => {
            if db_err.contains("not found") {
                Err(AppError::UserNotFound(user_id))
            } else {
                Err(AppError::DatabaseError(db_err))
            }
        }
    }
}

// モックデータベース関数
async fn fetch_user_from_db(user_id: u32) -> Result<String, String> {
    if user_id % 2 == 0 {
        Ok(format!("User data for ID {user_id}"))
    } else {
        Err("User not found in database".to_string())
    }
}

これで、エラー型がより多くのコンテキストを持つようになり、デバッグとエラー処理がはるかに明確になります。

Fromによるシームレスなエラー変換

get_user_complex関数は、依然としてfetch_user_from_dbからのStringエラーをAppError::DatabaseErrorに手動でマッピングしています。これは面倒になる可能性があります。Fromトレイトを活用して、互換性のあるエラーを?演算子を使用してAppError enumに自動的に変換できます。

別の外部サービスエラー、あるいはstd::io::ErrorなどがAppErrorバリアントとして存在すると仮定しましょう。

// より簡単なエラー変換のためにFromを実装
implement From<std::io::Error> for AppError {
    fn from(err: std::io::Error) -> Self {
        AppError::IOError(err)
    }
}

// モックDBが実際のエラー型を返した場合、それも変換できます。
// デモンストレーションのため、パースエラーを仮定します。
#[derive(Debug, Display, Error)]
#[display(fmt = "Parse error: {}", _0)]
pub struct ParseError(String);

implement From<ParseError> for AppError {
    fn from(err: ParseError) -> Self {
        AppError::InvalidInput(format!("Parsing failed: {}", err))
    }
}


// `io::Error` のために`?` を使用するサービス関数
async fn read_user_file(file_path: &str) -> Result<String, AppError> {
    let content = std::fs::read_to_string(file_path)?;
    Ok(content)
}

これにより、エラー伝播ロジックが大幅にクリーンアップされ、成功パスに集中できるようになります。

Webフレームワークとの統合：IntoResponseトレイト

Webサービスにとって、エラーは内部状態であるだけでなく、クライアントが理解できるHTTPレスポンスに変換される必要があります。これには通常、適切なHTTPステータスコード（例: 404 Not Found, 500 Internal Server Error, 400 Bad Request）と、エラーを記述するJSONボディの設定が含まれます。多くのRust Webフレームワークは、Axumのようなこのためのトレイトを提供しています。

AppErrorをHTTPレスポンスに直接変換できるようにしましょう。

use axum::{
    body::Bytes,
    response::{IntoResponse, Response},
    http::StatusCode,
    Json,
};
use serde::Serialize; // エラー詳細をJSONにシリアライズするため

#[derive(Serialize)]
struct ErrorResponse {
    code: u16,
    message: String,
    details: Option<String>,
}

implement IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, error_message, details) = match self {
            AppError::UserNotFound(_) => (StatusCode::NOT_FOUND, self.to_string(), None),
            AppError::DatabaseError(msg) => (StatusCode::INTERNAL_SERVER_ERROR, "Database operation failed".to_string(), Some(msg)),
            AppError::IOError(err) => (StatusCode::INTERNAL_SERVER_ERROR, "File system error".to_string(), Some(err.to_string())),
            AppError::InvalidInput(msg) => (StatusCode::BAD_REQUEST, "Invalid request input".to_string(), Some(msg)),
        };

        // デバッグのために内部でエラーをログ記録
        eprintln!("Error: {}", self);

        let error_body = Json(ErrorResponse {
            code: status.as_u16(),
            message: error_message,
            details,
        });

        (status, error_body).into_response()
    }
}

// カスタムエラーを使用したAxumハンドラの例
async fn get_user_handler(
    axum::extract::Path(user_id): axum::extract::Path<u32>,
) -> Result<Json<String>, AppError> {
    let user_data = get_user_complex(user_id).await?;
    Ok(Json(user_data))
}

// 実際のAxumアプリケーションでは、このハンドラを登録します
// fn main() {
//     let app = axum::Router::new().route("/users/:id", axum::routing::get(get_user_handler));
//     // ... サーバーを実行
// }

この強化された例では:

  1. クライアントに返されるJSONエラーの形式を標準化するために、ErrorResponse構造体を定義しました。
  2. AppErrorに対してIntoResponseを実装しました。この実装内では、各AppErrorバリアントを適切なHTTP StatusCodeにマッピングし、Jsonレスポンスボディを構築します。
  3. get_user_handler内の?演算子は、get_user_complexによって返された任意のAppErrorをIntoResponse互換のエラーにシームレスに変換し、AxumはそれをHTTPレスポンスの生成に使用します。

この最終ステップはエラー処理の旅を完了させ、Webサービスが内部アプリケーションエラーを構造化されたクライアントフレンドリーなHTTPレスポンスに自動的に変換できるようにし、APIを堅牢で予測可能で、魅力的なものにします。

結論

シンプルなResult型からエラー処理を開始することは、Rustでエラーを処理するための素晴らしい方法ですが、複雑なWebサービスでは、カスタムエラーenumに移行することで、必要な明瞭さと構造が得られます。ErrorおよびDisplayトレイトを実装し、Fromによるシームレスな変換とIntoResponse（Webフレームワーク用）を活用することで、開発者は内部開発に表現力豊かで、外部クライアントとの通信に完璧に適合したエラー処理システムを構築できます。この包括的なアプローチは、潜在的な混乱を予測可能で、優雅な失敗に変換します。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts