序章
この質問は、最終的に、Bluebird での開発中に発生した問題を解決することを目的としています。ただし、いくつかのことを明確にする機会も利用しているため、補足的な質問があります。また、今後のストーリーを読んでいるときに混乱や退屈を感じる可能性があることをあらかじめお詫び申し上げます。
質問
私の理解では、Bluebird は次の戦略に従って、無視された拒否をインテリジェントにキャッチしようとします。
2 番目のアプローチは、bluebird がデフォルトで採用しているもので、2 番目のターンの開始までに拒否が処理されない場合に、登録済みのハンドラーを呼び出すことです。-- Bluebird Readme # エラー処理
ここで、最初の副次的な質問があります。「第 2 ターンの開始」とはどういう意味ですか?
同じセクションの後半で、次のことが文書化されています。
もちろん、これは完璧ではありません.Promiseがしばらくぶらぶらしていた後、何らかの理由でコードが急いでエラーハンドラーをPromiseに添付する必要がある場合、迷惑なメッセージが表示されます. その場合、.done() メソッドを使用して、ハングしている例外をスローする必要があることを通知できます。-- Bluebird Readme # エラー処理
さて、私のユースケースは次のとおりで、上記の状況に遭遇したと思います。
を添付する promise を提供する関数を呼び出します
.catch()
。lib.loadUrls() .catch(function(e){console.log(e);});
内部的に、その関数は URL1 からコンテンツをロードし、コンテンツに基づいて URL2 からコンテンツを順番にロードします。
lib.loadUrls = return this.loadUrl1() .then(this.loadUrl2.bind(this))
このチェーンの 2 番目の promise が拒否された場合、エラーは最初に catch によって処理され、次に Bluebirds
Possibly unhandled error
ハンドラーによっても処理されます。
この最後の動作は望ましくなく、なぜこれを行っているのかわかりません。したがって、質問 2 は次のようになります。エラー ハンドラがアタッチされて実行されているにもかかわらず、Bluebird はエラーが「未処理」である可能性を考慮しているのはなぜですか?
どうやら、拒否が.catch()
. その場合、(引用されたドキュメントによると)「を使用して.done()
」解決する必要があります。
今、私はいくつかのことを試しましたが、このシナリオで「.done を使用する」方法がよくわかりません。.done()
( undefinedを返すのは役に立たず、私が.finally
-ing できなくなります。)
したがって、これは私.done()
の 3 番目と 4 番目の質問を紹介します。.finally()
編集1:バグを再現するためにいくつかのJSFiddlesを作成しました:
- Bluebird 1.0.5 を使用すると、バグが再現されます。
- 最新の Bluebird.js を使用するとバグが再現されます (現時点では)
- ベータ バージョン 0.10.0-1 を使用 しても、バグは再現されません。
編集 2:開発者はバグを修正しました。