Мне действительно нужно иметь обработку исключений в этом простом асинхронном сценарии RxJava? - PullRequest
Новая
       7

Мне действительно нужно иметь обработку исключений в этом простом асинхронном сценарии RxJava?

0 голосов
/ 22 мая 2018

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

Этот блок такой (некоторые имена изменены): 

public ShippingMethodHolder callClientsAsync(ShippingMethodContext shippingContext) {
    Single<ShippingMethodResponse> productOneResponseEntity = Single.<ShippingMethodResponse>create(source -> {
        source.onSuccess(getProductOneowShippingMethodResponse(shippingContext));
    }).subscribeOn(Schedulers.io());

    Single<ShippingMethodResponse> productTwoResponseEntity = Single.<ShippingMethodResponse>create(source -> {
        source.onSuccess(getProductTwoShippingMethodResponse(shippingContext));
    }).subscribeOn(Schedulers.io());

    Single<ShippingMethodHolder> singleProductCartResponseHolder = Single.zip(productOneResponseEntity, productTwoResponseEntity,
            (dtvResponse, productTwoResponse) -> {
                return new ShippingMethodHolder(dtvResponse, productTwoResponse);
            });
    return singleProductCartResponseHolder.blockingGet();
}

Комментарий сделан по поводуэтот код от людей, более информированных об этом, по существу говорит о том, что здесь отсутствует обработка исключений RxJava «и это приведет к блокировке или падению потока».Я предполагаю, что это относится к тому факту, что два асинхронных вызова имеют вызовы onSuccess (), но не вызывают вызовы onError ().

Однако это кажется мне странным.Область, в которой вызывается onSuccess (), предназначена не для успеха или неудачи бизнес-логики, а для попытки RxJava сделать асинхронный вызов.

Я мог бы воспользоваться некоторыми советами о том, действительно ли это проблемас точки зрения RxJava.

1 Ответ

0 голосов
/ 22 мая 2018

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

Single<ShippingMethodResponse> productOneResponseEntity = 
    Single.<ShippingMethodResponse>fromCallable(() -> 
        getProductOneowShippingMethodResponse(shippingContext)
    )
    .subscribeOn(Schedulers.io());

В зависимости от типа приложения блокирующее ожидание результата может быть нежелательным, особенно если методвызывается из потока пользовательского интерфейса.Вы можете вернуть zip Single и продолжать сочинение до тех пор, пока не будет выпущено окончательное subscribe().

Комментарий, сделанный об этом коде от людей, более информированных об этом, по существу говорит, что это исключение RxJava отсутствуетобработка "и вызовет блокировку или сбой потока"

Оригинальные create и fromCallable поймают ваше исключение и попытаются сообщить об этом потребителю.В этом случае blockingGet перезапустит одно из исключений источника в потоке вызывающего, а другое (если оно есть) будет перенаправлено в глобальный обработчик RxJavaPlugins.onError.Они, вероятно, имели в виду, что вызывающий ваш метод обычно не ожидает, что он сгенерирует, поэтому они могут пропустить try-catch вокруг него и потерпеть неудачу во время выполнения.Решение действительно зависит от того, какой тип управления ошибками вы намеревались использовать в приложении.

...