MENU
  1. ホーム
  2. Rust
  3. Rustでクレート間のエラー型を共有する設計ガイドと実装例

Rustでクレート間のエラー型を共有する設計ガイドと実装例

Rust

Rustにおけるエラー処理は、安全性と効率性を追求したシステムの設計において重要な役割を果たします。複数のクレート（ライブラリ）を組み合わせて開発する際、エラー型がクレートごとに異なるとエラー処理が煩雑になることがあります。この問題を解消するために、共通のエラー型を設計し、クレート間で共有する方法が求められます。

この記事では、Rustでエラー型を共有する設計方法やそのメリットについて詳しく解説します。エラー型を共通化することで、エラー処理の一貫性を保ち、保守性や再利用性を向上させることが可能です。また、thiserrorやanyhowといった便利なクレートを活用することで、エラー管理を効率的に行う方法についても紹介します。Rustのエラー処理をより効果的に実践したい開発者にとって、役立つ内容となるでしょう。

目次

Rustにおけるエラー処理の基本概念

Rustのエラー処理は、安全性を重視した設計となっており、エラーの種類や発生場所を明確にすることが求められます。Rustには主に2つのエラー処理の方法があります。

1. パニックによるエラー処理


プログラムの異常な状態で発生するエラーには、panic!マクロを使用します。これはプログラムを即座に終了し、エラーメッセージを出力する方法です。例えば、配列の範囲外アクセスはパニックを引き起こします。

fn main() {
    let v = vec![1, 2, 3];
    println!("{}", v[4]); // パニックが発生する
}

2. `Result`型によるエラー処理


回復可能なエラーには、Result型を使用します。Result型は、成功と失敗の2つの状態を表す列挙型で、以下のように定義されています。

enum Result<T, E> {
    Ok(T),
    Err(E),
}
  • Ok(T): 成功時に値 T を返します。
  • Err(E): 失敗時にエラー型 E を返します。

例: ファイルの読み込み処理

use std::fs::File;

fn read_file() -> Result<File, std::io::Error> {
    let f = File::open("test.txt")?;
    Ok(f)
}

このようにResult型を利用することで、エラーを呼び出し元に伝播させることができます。

`Error`トレイトについて


Rustでは、エラー型として任意の型を使用できますが、標準ライブラリのErrorトレイトを実装すると、より一貫したエラー処理が可能になります。Errorトレイトを実装した型は、他のクレートやライブラリと互換性が高くなります。

カスタムエラー型の例

use std::fmt;
use std::error::Error;

#[derive(Debug)]
struct CustomError;

impl fmt::Display for CustomError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "Custom error occurred")
    }
}

impl Error for CustomError {}

Rustのエラー処理は柔軟性があり、安全性を高める設計となっています。エラー処理の基本を理解することで、クレート間でのエラー型の共有設計がスムーズになります。

エラー型を共有するメリット

Rustの複数のクレート間でエラー型を共有する設計には、いくつかの重要な利点があります。特に、大規模なプロジェクトやマイクロサービスアーキテクチャにおいては、エラー型を統一することで、コードの一貫性や保守性が向上します。

1. エラー処理の一貫性


エラー型を共有することで、異なるクレート間でのエラー処理が統一されます。呼び出し元のクレートでエラーをキャッチする際、エラー型が一貫しているため、分岐処理がシンプルになります。

fn handle_error(err: SharedError) {
    match err {
        SharedError::IoError(e) => println!("IOエラー: {}", e),
        SharedError::ParseError => println!("パースエラーが発生しました"),
    }
}

2. コードの再利用性向上


共通のエラー型を定義しておくことで、複数のクレートでそのエラー型を使い回すことができます。新たにエラー型を作成する手間が省け、冗長なコードが減少します。

3. 保守性と拡張性の向上


エラー型が共通であれば、変更や追加が容易です。例えば、新たなエラーケースを追加する際、共有エラー型を更新するだけで済み、すべての依存クレートがその変更を反映できます。

4. 依存関係のシンプル化


共通エラー型を独立したクレートに定義することで、依存関係が明確になります。各クレートはこのエラー型クレートだけに依存すればよく、依存関係の複雑さが軽減されます。

例: 共通エラー型を定義したクレート

// shared_error.rs
#[derive(Debug)]
pub enum SharedError {
    IoError(std::io::Error),
    ParseError,
}

これを他のクレートでインポートして利用します。

use shared_error::SharedError;

fn read_file() -> Result<String, SharedError> {
    let content = std::fs::read_to_string("data.txt").map_err(SharedError::IoError)?;
    Ok(content)
}

5. 統一されたトラブルシューティング


エラー型が統一されているため、ログ出力やデバッグ時にエラーの特定が容易になります。エラー処理のロジックが一箇所に集約されるため、問題の特定と解決が効率的になります。

エラー型をクレート間で共有することで、プロジェクト全体のエラー管理が効率化され、メンテナンスの手間を大幅に削減できます。

エラー型を定義するクレートの作成方法

複数のクレートでエラー型を共有するためには、まず共通のエラー型を定義する専用クレートを作成するのが効果的です。これにより、エラー型を一箇所に集約し、再利用性と保守性を高めることができます。以下は、その手順を説明します。

1. エラー型クレートの作成


まず、新しいクレートを作成します。クレート名はわかりやすい名前にするのがベストです。

cargo new shared_error

作成したshared_errorクレートには、Cargo.tomlファイルが生成されます。

2. エラー型の定義


src/lib.rsに共通エラー型を定義します。thiserrorクレートを使用すると、エラー型の定義が簡潔になります。

shared_error/Cargo.toml に依存関係を追加します。

[dependencies]
thiserror = "1.0"

shared_error/src/lib.rs

use thiserror::Error;

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("I/Oエラーが発生しました: {0}")]
    IoError(#[from] std::io::Error),

    #[error("パースエラーが発生しました")]
    ParseError,

    #[error("不正なデータ: {0}")]
    InvalidData(String),
}

3. クレートを公開する


エラー型を他のクレートから利用できるように、モジュールを公開します。

pub use self::SharedError;

4. 依存クレートでの利用


他のクレートからshared_errorクレートを利用するには、Cargo.tomlに依存関係として追加します。

Cargo.toml

[dependencies]
shared_error = { path = "../shared_error" }

エラー型をインポートして使用します。

使用例:

use shared_error::SharedError;
use std::fs::File;

fn read_config_file() -> Result<File, SharedError> {
    let file = File::open("config.toml").map_err(SharedError::IoError)?;
    Ok(file)
}

fn main() {
    match read_config_file() {
        Ok(_) => println!("ファイルを正常に読み込みました。"),
        Err(e) => eprintln!("エラー: {}", e),
    }
}

5. ビルドと確認


全体のプロジェクトをビルドして、エラー型が正しく共有されていることを確認します。

cargo build

まとめ


エラー型を専用クレートで定義することで、複数のクレート間で一貫したエラー処理が可能になります。thiserrorを活用すると、カスタムエラー型の定義がシンプルになり、保守性が向上します。

カスタムエラー型の設計ポイント

Rustでカスタムエラー型を設計する際、複数のクレートで使いやすく、保守しやすいエラー型を作成するために考慮すべきポイントがあります。これらのポイントを押さえることで、エラー処理の効率と一貫性が向上します。

1. エラー型はシンプルに保つ


カスタムエラー型は、必要最小限のエラーケースを持つように設計するのが理想です。複雑すぎるエラー型はメンテナンスが困難になります。例えば、一般的なI/Oエラーとパースエラーのみを定義することが考えられます。

use thiserror::Error;

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("I/Oエラー: {0}")]
    IoError(#[from] std::io::Error),

    #[error("パースエラー")]
    ParseError,
}

2. `thiserror`と`anyhow`を活用する


カスタムエラー型の定義にはthiserrorを、汎用的なエラー処理にはanyhowを使用すると効率的です。thiserrorはカスタムエラー型を簡潔に定義でき、anyhowはエラーの種類に依存しない柔軟なエラー処理が可能です。

`thiserror`を用いたカスタムエラー型

use thiserror::Error;

#[derive(Debug, Error)]
pub enum MyError {
    #[error("ファイルエラー: {0}")]
    FileError(#[from] std::io::Error),

    #[error("無効な入力: {0}")]
    InvalidInput(String),
}

`anyhow`を用いた柔軟なエラー処理

use anyhow::{Result, Context};

fn read_file() -> Result<String> {
    let content = std::fs::read_to_string("config.txt")
        .context("ファイルの読み込みに失敗しました")?;
    Ok(content)
}

3. エラー型に詳細な情報を含める


エラーの詳細情報を含めることで、デバッグやログ出力がしやすくなります。具体的な原因や関連するデータをエラー型に追加すると効果的です。

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("不正なデータ: {0}")]
    InvalidData(String),

    #[error("接続エラー: サーバー {server}、エラーコード {code}")]
    ConnectionError { server: String, code: u16 },
}

4. `std::error::Error`トレイトの実装


カスタムエラー型にstd::error::Errorトレイトを実装することで、標準ライブラリのエラー処理と互換性が向上します。

use std::fmt;
use std::error::Error;

#[derive(Debug)]
pub struct CustomError;

impl fmt::Display for CustomError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "カスタムエラーが発生しました")
    }
}

impl Error for CustomError {}

5. エラー型の変換をサポートする


異なる種類のエラーをカスタムエラー型に変換できるようにすることで、エラー処理が柔軟になります。Fromトレイトを実装すると、エラーの変換が簡単になります。

impl From<std::io::Error> for SharedError {
    fn from(err: std::io::Error) -> Self {
        SharedError::IoError(err)
    }
}

6. ドキュメントとコメントを追加する


エラー型に適切なドキュメントコメントを追加し、各エラーケースの意味や用途を明確にすることで、他の開発者が理解しやすくなります。

/// 共通のエラー型
#[derive(Debug, Error)]
pub enum SharedError {
    /// I/O操作で発生するエラー
    #[error("I/Oエラー: {0}")]
    IoError(#[from] std::io::Error),

    /// データパース時のエラー
    #[error("パースエラー")]
    ParseError,
}

まとめ


カスタムエラー型を設計する際は、シンプルさ、詳細情報の提供、標準トレイトの実装、エラー変換のサポートを考慮しましょう。thiserrorやanyhowを活用することで、効率的なエラー処理が可能になり、クレート間で一貫性のあるエラー管理が実現できます。

`thiserror`と`anyhow`の活用方法

Rustで効率的にエラー処理を行うために、thiserrorとanyhowという2つのクレートを活用するのが一般的です。これらのクレートを組み合わせることで、シンプルかつ柔軟なエラー管理が可能になります。それぞれの特徴と使い方について詳しく解説します。

`thiserror`クレートの概要

thiserrorはカスタムエラー型を簡潔に定義するためのクレートです。std::error::Errorトレイトの実装が容易になり、エラーメッセージのフォーマットもシンプルに指定できます。主にライブラリやクレート内でエラー型を定義する際に利用されます。

`thiserror`の導入

Cargo.toml に依存関係を追加します。

[dependencies]
thiserror = "1.0"

カスタムエラー型の定義例

以下はthiserrorを使用したカスタムエラー型の例です。

use thiserror::Error;

#[derive(Debug, Error)]
pub enum MyError {
    #[error("I/Oエラーが発生しました: {0}")]
    IoError(#[from] std::io::Error),

    #[error("データのパースに失敗しました")]
    ParseError,

    #[error("無効な入力: {0}")]
    InvalidInput(String),
}

関数での利用例

カスタムエラー型を利用してエラーを返す関数の例です。

use std::fs::File;

fn open_file(path: &str) -> Result<File, MyError> {
    let file = File::open(path)?;
    Ok(file)
}

fn main() {
    match open_file("config.txt") {
        Ok(_) => println!("ファイルを正常に開きました。"),
        Err(e) => eprintln!("エラー: {}", e),
    }
}

`anyhow`クレートの概要

anyhowは汎用的なエラー処理を提供するクレートです。具体的なエラー型を意識せずにエラーを扱えるため、特にアプリケーションレベルで便利です。エラー型の定義が不要で、シンプルにエラーを扱いたい場合に最適です。

`anyhow`の導入

Cargo.toml に依存関係を追加します。

[dependencies]
anyhow = "1.0"

`anyhow`を使ったエラー処理の例

anyhow::Resultを使って関数のエラーを簡単に返せます。

use anyhow::{Context, Result};
use std::fs::File;

fn read_file(path: &str) -> Result<File> {
    let file = File::open(path).with_context(|| format!("Failed to open file: {}", path))?;
    Ok(file)
}

fn main() -> Result<()> {
    let _file = read_file("config.txt")?;
    println!("ファイルを正常に読み込みました。");
    Ok(())
}

`thiserror`と`anyhow`の併用

ライブラリ側でthiserrorを用いてカスタムエラー型を定義し、アプリケーション側でanyhowを用いてエラーを柔軟に処理する設計が一般的です。

併用例

カスタムエラー型の定義 (thiserror)

use thiserror::Error;

#[derive(Debug, Error)]
pub enum MyError {
    #[error("I/Oエラー: {0}")]
    IoError(#[from] std::io::Error),

    #[error("パースエラー")]
    ParseError,
}

アプリケーション側 (anyhow)

use anyhow::Result;
use std::fs::File;
use my_error::MyError;

fn open_file(path: &str) -> Result<File, MyError> {
    let file = File::open(path)?;
    Ok(file)
}

fn main() -> Result<()> {
    match open_file("config.txt") {
        Ok(_) => println!("ファイルを正常に開きました。"),
        Err(e) => eprintln!("エラー: {}", e),
    }
    Ok(())
}

まとめ

  • thiserror はライブラリやクレートでカスタムエラー型を定義する際に使用します。
  • anyhow はアプリケーションで柔軟にエラーを処理したい場合に使用します。

この2つを組み合わせることで、効率的で一貫性のあるエラー処理が実現できます。

クレート間でのエラー型共有の実装例

ここでは、Rustで複数のクレート間でエラー型を共有する具体的な実装例を紹介します。共通のエラー型を専用クレートに定義し、それを他のクレートで利用する手順を順を追って解説します。

1. 共通エラー型クレートの作成

まず、共通エラー型を定義するクレートを作成します。ここではshared_errorという名前のクレートを作ります。

cargo new shared_error

shared_error/Cargo.toml

[dependencies]
thiserror = "1.0"

shared_error/src/lib.rs

use thiserror::Error;

/// 共通エラー型の定義
#[derive(Debug, Error)]
pub enum SharedError {
    #[error("I/Oエラーが発生しました: {0}")]
    IoError(#[from] std::io::Error),

    #[error("データのパースに失敗しました")]
    ParseError,

    #[error("無効な入力: {0}")]
    InvalidInput(String),
}

2. 共通エラー型を利用するクレートの作成

次に、この共通エラー型を使用するクレートを作成します。ここではappという名前のクレートを作成し、shared_errorクレートに依存させます。

cargo new app

app/Cargo.toml

[dependencies]
shared_error = { path = "../shared_error" }

3. 共通エラー型を使った関数の実装

shared_errorクレートからエラー型をインポートし、エラーを返す関数を作成します。

app/src/main.rs

use shared_error::SharedError;
use std::fs::File;

/// ファイルを開く関数
fn open_file(path: &str) -> Result<File, SharedError> {
    let file = File::open(path).map_err(SharedError::IoError)?;
    Ok(file)
}

fn main() {
    match open_file("config.txt") {
        Ok(_) => println!("ファイルを正常に開きました。"),
        Err(e) => eprintln!("エラー: {}", e),
    }
}

4. プロジェクトのビルドと実行

プロジェクトのルートディレクトリで、以下のコマンドを実行してビルドし、動作を確認します。

cargo run --manifest-path app/Cargo.toml

ファイルが存在しない場合、以下のようなエラーメッセージが出力されます。

エラー: I/Oエラーが発生しました: No such file or directory (os error 2)

5. 複数のクレートでの再利用

同様に、他のクレートでもshared_errorクレートを依存関係に追加することで、共通のエラー型を再利用できます。

例: 別クレート parser の作成

cargo new parser

parser/Cargo.toml

[dependencies]
shared_error = { path = "../shared_error" }

parser/src/lib.rs

use shared_error::SharedError;

/// データをパースする関数
pub fn parse_data(data: &str) -> Result<(), SharedError> {
    if data.is_empty() {
        return Err(SharedError::InvalidInput("データが空です".to_string()));
    }
    Ok(())
}

まとめ

この実装例では、共通エラー型をshared_errorクレートに定義し、複数のクレートでそのエラー型を共有する方法を解説しました。これにより、エラー処理が一貫し、コードの再利用性と保守性が向上します。

エラー型共有における注意点とトラブルシューティング

Rustでクレート間のエラー型を共有する際には、いくつかの注意点や潜在的な問題があります。これらのポイントを理解しておくことで、エラー処理の設計がスムーズになり、問題の発生を未然に防ぐことができます。

1. 依存関係のバージョン管理

共通エラー型を定義するクレートを他のクレートで利用する場合、依存関係のバージョン管理に注意が必要です。複数のクレートで異なるバージョンのエラー型を使用すると、互換性の問題が発生します。

対策:

  • すべての依存クレートで共通エラー型クレートのバージョンを揃える。
  • Cargo.tomlのバージョン指定を正確に管理し、互換性を保つ。
[dependencies]
shared_error = "0.1.0"  # バージョンを固定する

2. エラー型の循環依存の回避

エラー型を定義するクレートが他のクレートと循環依存関係になると、ビルドエラーが発生します。エラー型クレートは、他のクレートに依存しないシンプルな構成にすることが重要です。

対策:

  • エラー型を定義するクレートには、エラー関連のコードのみを含める。
  • 他のクレートへの依存を避け、独立性を保つ。

3. エラー型の拡張と互換性

共通エラー型に新しいエラーケースを追加する際、後方互換性を意識しないと、依存するクレートでエラーが発生する可能性があります。

対策:

  • 互換性を維持するため、既存のエラー型を変更せず、新しいエラー型を追加する形で拡張する。
  • バージョンを更新する際は、適切なセマンティックバージョニングを適用する。

互換性を保つエラー型の拡張例

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("I/Oエラー: {0}")]
    IoError(#[from] std::io::Error),

    #[error("パースエラー")]
    ParseError,

    #[error("無効な入力: {0}")]
    InvalidInput(String),

    // 新しいエラーケースを追加
    #[error("ネットワークエラー: {0}")]
    NetworkError(String),
}

4. エラーハンドリング時のパフォーマンス

エラー処理が過度に複雑だと、パフォーマンスに影響することがあります。特に、頻繁にエラーを変換する場合には注意が必要です。

対策:

  • 必要以上にエラーをラップしない。
  • 頻繁に発生するエラーは、シンプルなエラー型で処理する。

5. エラー情報の適切な出力

エラーメッセージが曖昧だと、デバッグやトラブルシューティングが難しくなります。エラー型には適切なコンテキスト情報を含めるようにしましょう。

対策:

  • エラー発生箇所や原因がわかるよう、具体的なメッセージを含める。
  • anyhowのwith_contextメソッドを活用して、詳細なエラーメッセージを追加する。

エラーコンテキストの追加例

use anyhow::{Context, Result};

fn read_config() -> Result<String> {
    std::fs::read_to_string("config.toml")
        .context("設定ファイルの読み込みに失敗しました")
}

6. トラブルシューティングのヒント

  • ビルドエラーが発生する場合:
    依存関係のバージョンが正しいか確認する。循環依存がないか調べる。
  • ランタイムエラーが発生する場合:
    エラーメッセージを詳細に確認し、どのクレートでエラーが発生しているか特定する。
  • エラー型が見つからない場合:
    use文で正しいパスを指定しているか確認する。

まとめ

クレート間でエラー型を共有する際は、依存関係の管理、循環依存の回避、後方互換性、エラー情報の適切な出力に注意しましょう。これらのポイントを押さえておけば、エラー処理が効率的で保守しやすいものになります。

ベストプラクティスと応用例

Rustでクレート間のエラー型を共有する際、効果的にエラー処理を行うためのベストプラクティスと応用例を紹介します。これらの手法を活用することで、コードの保守性や再利用性が向上し、エラー処理がより効率的になります。

1. 共通エラー型を専用クレートに分離する

共通エラー型は独立したクレートに定義し、他のクレートから参照する形にすることで、エラー型の管理が容易になります。

例: shared_errorクレートの構成

shared_error/
├── Cargo.toml
└── src/
    └── lib.rs

shared_error/src/lib.rs

use thiserror::Error;

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("I/Oエラー: {0}")]
    IoError(#[from] std::io::Error),
    #[error("パースエラー")]
    ParseError,
    #[error("無効なデータ: {0}")]
    InvalidData(String),
}

2. エラー型をモジュール化する

エラー型が増えてきた場合、用途ごとにモジュール化することで、コードが整理され、読みやすくなります。

例: エラー型のモジュール化

pub mod io_errors {
    use thiserror::Error;

    #[derive(Debug, Error)]
    pub enum IoError {
        #[error("ファイルが見つかりません: {0}")]
        FileNotFound(String),
        #[error("読み込みエラー: {0}")]
        ReadError(#[from] std::io::Error),
    }
}

pub mod parse_errors {
    use thiserror::Error;

    #[derive(Debug, Error)]
    pub enum ParseError {
        #[error("JSONのパースエラー")]
        JsonParseError,
        #[error("YAMLのパースエラー")]
        YamlParseError,
    }
}

3. `anyhow`でアプリケーションエラーをシンプルに処理

ライブラリ側でthiserrorを使用してカスタムエラー型を定義し、アプリケーション側ではanyhowを使って柔軟にエラー処理を行うのが効果的です。

例: anyhowを使ったエラー処理

use anyhow::{Context, Result};
use shared_error::SharedError;

fn read_config_file(path: &str) -> Result<String, SharedError> {
    let content = std::fs::read_to_string(path).context("設定ファイルの読み込みに失敗しました")?;
    Ok(content)
}

fn main() -> Result<()> {
    match read_config_file("config.toml") {
        Ok(content) => println!("ファイル内容: {}", content),
        Err(e) => eprintln!("エラー: {}", e),
    }
    Ok(())
}

4. エラーに追加情報を含める

エラー発生時にデバッグ情報やコンテキストを含めることで、問題の特定が容易になります。

例: エラーに追加情報を含める

use thiserror::Error;

#[derive(Debug, Error)]
pub enum SharedError {
    #[error("ファイルエラー: {path}")]
    FileError {
        path: String,
        #[source]
        source: std::io::Error,
    },
}

fn read_file(path: &str) -> Result<String, SharedError> {
    std::fs::read_to_string(path).map_err(|e| SharedError::FileError {
        path: path.to_string(),
        source: e,
    })
}

5. テストでエラー処理を確認する

エラー処理が正しく動作するか、テストを通じて確認することが重要です。

例: エラー処理のテスト

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_read_file_error() {
        let result = read_file("nonexistent.txt");
        assert!(result.is_err());
    }
}

6. ログ出力を活用する

エラー発生時にログを出力することで、運用中のトラブルシューティングが容易になります。logクレートとenv_loggerを使うと便利です。

Cargo.tomlに依存関係を追加

[dependencies]
log = "0.4"
env_logger = "0.10"

ログ出力の例

use log::error;
use shared_error::SharedError;

fn handle_error(err: SharedError) {
    error!("エラーが発生しました: {}", err);
}

fn main() {
    env_logger::init();
    if let Err(e) = read_file("config.toml") {
        handle_error(e);
    }
}

まとめ

エラー型を共有する際は、専用クレートの作成、モジュール化、thiserrorとanyhowの活用、エラー情報の充実、テストやログ出力などを組み合わせることで、効率的で保守性の高いエラー処理が実現できます。これらのベストプラクティスを参考に、より堅牢なRustアプリケーションを構築しましょう。

まとめ

本記事では、Rustにおけるクレート間でエラー型を共有する設計方法について解説しました。共通エラー型を専用クレートで定義し、thiserrorやanyhowといった便利なクレートを活用することで、エラー処理の効率性や保守性を向上させる手法を紹介しました。

エラー型を共有することで、エラー処理の一貫性が保たれ、コードの再利用性やデバッグのしやすさが向上します。また、バージョン管理や循環依存に注意し、テストやログ出力を適切に組み合わせることで、より堅牢なシステムが構築できます。

これらのベストプラクティスを活用し、効率的で信頼性の高いRustアプリケーションのエラー管理を実践してください。

Rust
Rust エラー型 クレート設計

コメント

コメントする

目次