unwrap や anyhow 使うか問題

[yuk1ty]

• unwrap を使用してよいか、できうる限り Result 型はエラーハンドリングするべきかの指針を決める。
  • main 関数内ではそれ以上伝播させる必要はないから、unwrap してしまってもよいのではと考えている。
  • unwrap は「こういう値は絶対来ないはずで、来たら何かがおかしいと言えるから unwrap しておく」みたいな箇所にも使うことがある。
• anyhow 使うか問題
  • 個人的には、 標準ライブラリになく外部クレート使うほどでもないパーツを共通化したい #39 にてある程度エラー型が共通化されたタイミングで使うのをやめたいと思っている。
  • 理由は、Rust の初心者の方が読んで anyhow::Result に一瞬面食らうと思うため。

[laysakura]

main 関数内ではそれ以上伝播させる必要はないから、unwrap してしまってもよいのではと考えている。

ほぼ同意です。ただし「main の中でほぼ全部のResultを unwrap している」となると、 ? を使ったほうが（関数分割したときなどに）良いなと思ってしまいます。

unwrap は「こういう値は絶対来ないはずで、来たら何かがおかしいと言えるから unwrap しておく」みたいな箇所にも使うことがある。

このケースはどちらかというと expect("絶対来ない理由") と書いたほうが良いプラクティスかと思います。
ただし強制するほどのことでもないとは思います。

anyhow 使うか問題
個人的には、 #39 にてある程度エラー型が共通化されたタイミングで使うのをやめたいと思っている。

ほぼ全面同意です。
共通エラーは用意しつつも学習用途ですし、Error型を自前で定義するのも良い勉強になるかと思うので使わなくても良い程度のものでイメージしています。
（ただしError型を使えばもっときれいに書けるようなケースでは積極的な使用をレビューで推奨）

ちなみに共通エラーは

• Errorトレイトを実装
• Fromstd::io::Error, Fromstd::fmt::Error など、よくあるエラーからの変換を実装

したようなものと考えて良いでしょうか？

[yuk1ty]

はい、共通のエラーは下記2点を想定しています。

• Errorトレイトを実装
• Fromstd::io::Error, Fromstd::fmt::Error など、よくあるエラーからの変換を実装