Nano Hash - криптовалюты, майнинг, программирование

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

Я очень новичок в 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.

22.05.2018

Ответы:


1

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

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

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

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

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

22.05.2018
  • Я мог бы использовать больше разъяснений вашего последнего абзаца. Вы предполагаете, что вызов blockingGet — это другая стратегия по сравнению с create или fromCallable? 22.05.2018
  • Я вижу, что create и fromCallable очень похожи как в том, как их можно использовать, так и в их реализации. Тот факт, что javadoc для каждого из этих методов сильно отличается, немного сбивает с толку. 22.05.2018
  • Это разные операторы для разных целей, отсюда и разница в документации. create/fromCallable — это сторона источника, а blockingGet — сторона потребителя, это две разные стороны, которые следует учитывать. 23.05.2018
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..