成功した場合、結果のない関数からエラーを返す慣習的な方法は何ですか？

Question

Rustでは、回復可能なエラーを処理するための慣用的な方法はResultを使用することです。たとえば、この機能は明らかに慣用的である：

もちろん

fn do_work() -> Result<u64, WorkError> {...} 

、またシングル、明らかに、障害状態を持っているので、代わりにオプションのタイプを使用する関数があります。慣用句の例は次のとおりです。

fn do_work() -> Option<u64> 

これはすべてドキュメントで簡単に説明しています。しかし、私は、関数が失敗する可能性があるのは混乱していますが、成功すると意味のある値はありません。次の2つの関数の比較：

fn do_work() -> Option<WorkError> 
// vs 
fn do_work() -> Result<(), WorkError> 

私はこれらのいずれかが、より慣用的である、または現実世界の錆コードでより頻繁に使用されるかわかりません。このような質問のための私のgo-toリソースはRustの本ですが、私はこれが "Error Handling"セクションで扱われているとは思いません。私は、他のRustのドキュメンテーションでも多くの運がなかった。

もちろん、これはかなり主観的ですが、私は、どちらの形式が慣用的であるか、または一方の形式が他の形式よりも優れている（または劣っている）のどちらかを述べる信頼できる情報源を探しています。 （また、GoとHaskellのように、 "値としてのエラー"を頻繁に利用する他の言語とどのように慣習が比較されているのか不思議です）。

Answer 1

fn do_work() -> Result<(), WorkError>を使用してください。

Result<(), WorkError>は、作業を完了したいが失敗する可能性があることを意味します。

Option<WorkError>は、エラーが発生する可能性がありますが、存在しない可能性があります。

do_work()と書くとエラーは発生しないようにしたいので、Result<(), WorkError>をお勧めします。

私はOption<WorkError>だけfn get_last_work_error() -> Option<WorkError>のような場合に使用することが予想されます。

Answer 2

錆が（と、...私は言語がどのように強く型付けされた測定方法に私を呼んでしないでくださいしてください）「かなり強く型付け」されます。つまり、Rustは一般的に、型があなたのために "発言"し、コードを文書化できるようにするための手段です。したがって、この機能を使用して読み込み可能なコードを書くのは慣習的です。

言い換えれば、あなたが求めている質問は、「どのタイプがその署名を読んだ人に機能するのかが最も優れているか」であるべきです。あなたが見ることができるResult<(), Workerror>について

がまっすぐfrom the docs

結果が成功（OK）または失敗（ERR）だから、

のいずれかを表しタイプで、あなたのケースのための専門は、それはあなたの関数を意味し、エラー（Err<WorkError>）があります場合、それは成功した（Ok<()>によって表される）、またはWorkErrorだ場合は何も返しません。これは、あなたの質問に関数を記述した方法のコードでは、非常に直接的な表現です。

Option<WorkError>またはOption<()>

にタイプオプションは、オプションの値を表し、これを比較します。すべてのオプションのいずれかでいくつかの値はNoneが含まれている、とんではない

あなたのケースでOption<WorkError>は次のようになります読者に "この関数はWorkErrorを返しますが、何も返さない"と言っています。 「何も返さない」場合は、関数が実際に成功したことを意味しますが、型だけではそれほど明白ではないことを示すことができます。

Option<()>はWorkErrorが（エラーの種類やエラーメッセージなどの）他の情報が含まれていないし、それが実質的に唯一の方法だ場合、「この関数は何も返さないか、意味のあるリターン持つことはできません」と言うための合理的なものになることができ、言います「エラーが発生しました」と言います。この場合、単純なboolには同じ情報が含まれています。そうでなければ、Resultは、エラーに関連する情報をさらに戻すことができます。