1

В RxJS версии 5, при выполнении следующего кода в процессе быть прекращен после трех итераций обоего подписок:Правильный способ иметь дело с ошибками, добавленных «onNext» для горячего, общего, наблюдаемых

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(); 

Однако, я понял, что ошибка, посланная в следующем обработчике, просто отменит подписку на эту конкретную подписку и не приведет к прекращению работы основного наблюдаемого. Мой ожидаемый результат будет заключаться в том, что подписка «One» будет отписана, но этот интервал будет продолжать давать результаты подписке «Два».

Такое поведение вызывает у меня проблемы, когда у меня может быть несколько подписей на лежащие в основе горячие наблюдаемые, но одно исключение, брошенное на любую из этих подписей, заставляет базовое наблюдаемое полностью прекратить действие.

Это особенно раздражает, когда я нахожусь в разработке с использованием горячей перезагрузки модуля, поскольку любая ошибка программирования в любой подписке заставляет меня обновлять всю страницу, чтобы повторно запустить наблюдаемые последовательности.

Есть ли способ, не обертывая каждый из моих подписок в try/catch, чтобы иметь исключение, брошенное в моем следующем обработчике, чтобы просто отказаться от подписки на ОДНУ подписку, а не прекратить базовую наблюдаемую?

------------ ------------ EDIT

Я нашел поведение, что я ищу, установив syncErrorThrowable в true для объекта подписки, возвращаемого «подписаться». Кажется, что единственный раз, когда это когда-либо задано true в базе кода, используется оператор «do».

Должен ли я воспользоваться этим полем? Я чувствую себя довольно грязным, используя его, но, с другой стороны, мне кажется странным, что оператор «do» имеет другую семантику обработки ошибок, чем «следующий» обработчик подписки.

Вот основной блок кода, пострадавших от этого флага: https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L132

Если он установлен в ложь, этот метод получает вызывается: https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L179

Принимая во внимание, если она установлена ​​истина, этот метод используется вместо : https://github.com/ReactiveX/RxJS/blob/master/src%2FSubscriber.ts#L188

Разница заключается в том, что первый метод будет перебрасывать исключение обратно в стоп-код, тогда как второй вместо этого распространяет ошибку на последующие Подписки.

Почему оператор do передает ошибку вперед, тогда как «следующий» обработчик затухает при ошибке? Мне это кажется странным.

ответ

1

Нет, не используйте это поле. Если вы измените его на true, ваша подписка начнет проглатывать ошибки.

Это немного личное состояние, которое мы используем, чтобы узнать, будет ли уведомление подписываться синхронно (в том же блоке, что и вызов подписки на источник Observable), или асинхронно. Если при синхронном уведомлении выдается ошибка с одного из обработчиков сообщений Подписчика, мы откладываем повторное бросок, пока не выйдем из обратного вызова подписки Observable.[1]

Если ваши обработчики выбрасывают ошибки, которые вы хотите переслать обработчику onError вашей подписки, настоящее руководство должно переместить их в блок do чуть выше подписки.

Нет, я не согласен с этим поведением. Вот несколько ссылок на контекст:

[1] Источник: Я написал этот кусок кода.

 Смежные вопросы

  • Нет связанных вопросов^_^