まとめ

3つのレッスンを通してhooqの基本的な使い方を紹介してきました。

レッスンでは触れられなかった細かい仕組みや仕様がまだまだあるので、気になった機能の紹介はぜひ個別のドキュメントを参照いただきたいです。

• リファレンス: 各機能に関しての詳細解説をしています。
• レシピ・アイデア集: あらかじめ用意されているフレーバーのソースコード利用例や、hooqのユースケース、隠し機能などを載せています。

他手段との比較

すべての関数に #[hooq] (や #[hooq(anyhow)] ) マクロを付与すると、エラーのスタックトレースに近いものを得られることを本チュートリアルで紹介しました！

本節ではおまけとして、スタックトレース(に近いもの)を得る他の手段との比較表を以下に示します。

凡例:

• 🌈: とても良い
• ✅: 良い
• ⚠️: あまり良くない
• ❌: 良くない

比較表解説:

• 学習コスト・自由度
  • ⚠️ Backtrace は RUST_LIB_BACKTRACE=1 環境変数の定義が必要な上、OSスレッドに依存するため利用にはRustの制御フローとは別の知識が求められます。
  • ⚠️ tracing はスタックトレースの取得を目的とした場合は過剰です。とはいえ、慣れていれば程よい選択肢と言えます。
  • 🌈 hooq は関数の頭にマクロを付けるだけです！
• 型定義の容易さ:
  • ⚠️ Backtrace を thiserror と併用する場合、予めエラー型のフィールドに含める必要があります。エラーを細分化しているほど後付けが大変になるか、あるいはエラー型の表現がシンプルではなくなるでしょう。
  • ✅ tracing には特に制約がないです。
  • ✅ hooq も、任意のエラーハンドリングクレートと相性が良いです！
• マクロレス:
  • 🌈 Backtrace はマクロを利用しなくて良いのが利点です！
  • ❌ tracing で手軽にスタックトレース相当の情報を得るには、#[tracing::instrument(err)] 等がほぼ必須です。
  • ❌ hooq は属性マクロクレートなので、マクロを使いたくない場合には利用できません。
• 情報量制御:
  • ⚠️ Backtrace が出力する通常のバックトレースは情報量が多すぎます😵
    • 生のバックトレースは、非同期の場合全く役に立ちませんし、多くの場合では過剰でしょう。
    • ただし、 color-eyre クレートを利用することで改善され、実用的になり得ます。
  • ✅ tracing は非同期の場合でも関数をたどることができます。一方、「何行目の ? 演算子か？」といった詳細な情報を得るには手動でロギングを入れるしかありません。
  • 🌈 hooq は (#[tracing::instrument] と同様に) #[hooq]を付けた関数についてのみトレースされるのでほしい箇所だけ的確に得られます。その上、 ? 演算子や return の位置まで取得でき、より細かい情報を得られます！
    • 属性マクロなので、test時や特定のfeatureが有効な時だけ #[cfg_attr(..., hooq(...))] で条件付き付与、といったことが可能です！
    • 💡 tracing と併用が可能なので、tracingの情報取得粒度を増やす使い方もできます！詳しくはフレーバーの tracing を見てください
• プラットフォームサポート:
  • ⚠️ Backtrace はプラットフォームによっては利用不可であることが公式ドキュメントに記述されています。
  • ✅ 通常のログ収集用途であればプラットフォームによる制約はないでしょう。
  • 🌈 ? にメソッドを挿入するだけなので、プラットフォーム依存の機能に頼ることはありません。各プラットフォームで工夫した使い方が可能です。
    • 💡 #[hooq::method(.unwrap()!)] で、 ? を unwrap のエイリアスとして利用する方法などもあります！