エラーハンドリングcrates の anyhow と thieerror の使い分け

コードの中のライブラリ側を書いているならば、ユーザが静的にチェック可能なエラー型を定義するべき。 thiserror を使えば簡便に定義できる。 エラーが起きたら panic (or なにかしらの代替処理) する前提のアプリケーション層側を書いているならば、デバッグの容易さを保持しつつ、エラー型の詳細をコード上から消去できるanyhow が便利。

anyhow

• アプリケーション向け
• std::error::Error を impl するエラー型を trait オブジェクト anyhow::Error を使って包めるっぽい？
• エラー型を返すAPIを使う側にて便利。デバッグに利用しやすい情報をエラー型に保持させつつ、trait オブジェクトにより実際のエラー型を消去。
  • 失敗したら最終的にpanicする系に便利。自作関数1つ1つのために自作エラー型を作るような手間を省ける。
  • 型消去されるため、エラーハンドリングの網羅性は静的に担保できなくなる。一応 downcast することで元のエラー型へアクセス可能だが、その必要があるならばエラー型を定義し網羅性確認可能にすべきだろう。

thiserror

• ライブラリ向け
• #[derive(thiserror::Error)] によりエラー型を簡便に定義できる。
• 自作APIのエラー定義に使うと便利。下位のAPIのエラー型を包みなおした自作エラー型を deriveマクロにより作成できる。 From<下位のエラー型> が実装されるため、そのまま伝搬することも可能になる。