1

RxJS バージョン 5 では、次のコードにより、両方のサブスクリプションを 3 回繰り返した後にプロセスが終了します。

var Rx = require("rxjs");

const published$ = Rx.Observable.interval(1000).publish();

published$.subscribe(index => {
    console.log(`One: ${index}`);

    if (index == 3) throw new Error("ded.");
});

published$.forEach(index => {
    console.log(`Two: ${index}`);
});

published$.connect();

ただし、次のハンドラーでスローされたエラーは、単にその特定のサブスクリプションのサブスクライブを解除し、基になるオブザーバブルを終了させないことを理解していました。私の予想される出力は、「1」のサブスクリプションがサブスクライブを解除することですが、間隔は「2」のサブスクリプションに結果を生成し続けます。

この動作により、基になるホット オブザーバブルに複数のサブスクリプションがある可能性があるという問題が発生しますが、これらのサブスクリプションのいずれかで単一の例外がスローされると、基になるオブザーバブルが完全に終了します。

ホット モジュール リロードを使用して開発している場合は特に厄介です。サブスクリプションでプログラミング エラーが発生すると、ページ全体を更新して監視可能なシーケンスを再開する必要があるためです。

各サブスクリプションを try/catch でラップせずに、次のハンドラーで例外をスローして、その 1 つのサブスクリプションを単にサブスクライブ解除し、基になるオブザーバブルを終了しないようにする方法はありますか?

- - - - - - 編集 - - - - - -

「subscribe」によって返されたサブスクリプション オブジェクトで syncErrorThrowable を true に設定することで、探している動作を見つけました。コードベースでこれが true に設定されるのは、「do」演算子を使用するときだけのようです。

このフィールドを利用する必要がありますか? 私はそれを使用するとかなり汚いと感じますが、一方で、「do」演算子が「next」サブスクリプションハンドラーとは異なるエラー処理セマンティクスを持っているのは奇妙です。

このフラグの影響を受ける主要なコード ブロックは次のとおりです: https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L132

false に設定すると、次のメソッドが呼び出されます: https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L179

true に設定されている場合は、代わりに次のメソッドが使用されます: https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L188

違いは、最初のメソッドは例外をコールスタックに再スローするのに対し、2 番目のメソッドはエラーを後続のサブスクリプションに転送することです。

do 演算子はエラーを前方に伝搬するのに、「next」ハンドラーはエラーをバブルバックするのはなぜですか? これは私には奇妙に思えます。

4

1 に答える 1

0

いいえ、そのフィールドは使用しないでください。これを true に戻すと、サブスクリプションはエラーを飲み込み始めます。

これは、サブスクリプションが同期的に (ソース Observable のサブスクライブ呼び出しと同じブロックで) 通知されているか、非同期で通知されているかを知るために使用する、ちょっとしたプライベートな状態です。同期通知中にサブスクライバーのメッセージ ハンドラーの 1 つからエラーがスローされた場合、Observable のサブスクライブ コールバックを終了するまでエラーの再スローを延期します。[1]

ハンドラーがサブスクリプションのハンドラーに転送したいエラーをスローする場合onError、現在のガイダンスでは、それらをdoサブスクリプションのすぐ上のブロックに移動します。

いいえ、私はこの振る舞いに同意しません。コンテキストのリンクをいくつか次に示します。

[1] ソース: このコードは私が書きました。

于 2016-03-03T03:37:32.023 に答える