エラーの原因を追跡する方法は？

Question

Resultタイプを使用するコードを記述するときに、ユーザーと開発者の動作が異なる場合があります。

• エラーを正常に処理するアプリケーションを作成する場合は、Resultを使用すると便利です。
• 開発中にエラーを「キャッチ」して、エラーを作成するコードの行を確認したり、値が作成された瞬間にスタックトレースを取得することができます。

エラーを検索するのは難しくありませんが、エラーが標準ライブラリからのものである場合、そのエラーは非常に一般的なものです。

たとえば、readコマンドが予期しないファイルの終わりを引き起こしたことを知ることは、手動でfile.read()?をfile.read().unwrap()に変更することなしには不可能です。

Resultからスタックトレースを取得する便利な方法はありますか？

弱いが実行可能な解決策は、読み込み用のマクロを作成することです。read_in_release_unwrap_in_debug!(file, data) ...これは非常に扱いにくいと感じています。

---

私は多くのreadコールを持つファイルリーダーを持っていますが、1つは失敗します。どちらが分からないのか分かりません。実行時に、結果を呼び出し側にプッシュしたいと思います。デバッグのために、失敗した読み込み呼び出しを停止するか、何らかの形で私の行番号を知らせたい。

Answer 1

結果自体にバックトレース情報はありませんが、カスタムエラータイプに追加できます。

error_chain crateはエラータイプを生成する例で、環境変数が設定されている場合に無料でバックトレース生成を取得します。

backtraceライブラリを直接使用して、自分で操作することもできます。