javascript - CommonJS promise の使用: 拒否と例外

Question

CommonJS promise ( QdownloadAsync()を使用) を返す関数があります。次の 2 つの方法で失敗する可能性があります。

(1) の場合、非同期が発生する前にわかっているため、例外をスローできます。(2)の場合、私は約束を拒否しなければなりません。

私の質問は、API を統一し、約束を拒否することで常にエラーを通知する必要があるかどうかです。または、すぐに判断できる無効な状態条件に対して例外をスローする必要がありますか? 別の例として、ユーザーが無効な引数を渡した場合、promise を拒否するよりもエラーをスローする方が賢明に思えます。

「例外的な」約束の拒否が実際にどのように行われるかについての明確さも同様に素晴らしいでしょう。そこでの使用法は、例外的な使用法と 1 対 1 で対応していますか?それとも例外的でない障害にも使用しますか?

score 3 · Accepted Answer

同期的に検出される可能性のある無効な入力が提示されたときに関数 (Q を実装する) が何をすべきかを知りたい場合は、Q のソースコードを調べて、Q が何をしたかを確認します。

例を次に示します。

if (fallback === undefined) {
    fallback = function (op) {
        return reject("Promise does not support operation: " + op);
    };
}

Q に無効な入力が提示されると、Q は拒否オブジェクトを使用してリゾルバーを呼び出します。したがって、基礎となるライブラリの動作を変更しようとするのではなく、API を同様に動作させることが正当化される可能性があります。

さらに、API を使用する人の視点から見てください。2 つまたは 1 つの例外処理コードパスを開発および維持したいですか?

score 0 · Accepted Answer

同期の場合について心配する必要はないと思います。promiseが機能する方法では、すでに解決された（または拒否された）promiseにコールバックが追加されたときに、コールバックが同期的に実行される必要があります。（まあ、少なくとも私が使っている道場ではそうです...）

拒否/例外を区別する唯一の理由は、promiseコールバック内から例外をスローできるとは思わないため、promiseをスローすることがアプリケーションにとって実際に重要である場合です。（繰り返しますが、これはDojoの約束であり、あなたの約束が100％確実ではありません...）

2 に答える 2