记一个Rxjava使用误区

最新推荐文章于 2022-09-21 18:21:02 发布

weixin_34332905

最新推荐文章于 2022-09-21 18:21:02 发布

阅读量791

点赞数

文章标签： java 移动开发 python

原文链接：https://my.oschina.net/zzxzzg/blog/2209611

版权

2019独角兽企业重金招聘Python工程师标准>>>

前言

经验主义害死人，我们知道rxjava提供了非常好的错误处理机制，所以在链式调用中的错误最终都会被subscribe中的onError接收到。但是事实真的是这样的吗？

例子

public static void test1(){
        mDisposable = Flowable.create(new FlowableOnSubscribe<Object>() {
            @Override
            public void subscribe(FlowableEmitter<Object> emitter) throws Exception {
                //比如进行一个网络请求
                try {
                    Thread.sleep(5000);
                }catch (Exception e){}
                //TODO
                boolean b = true; // 模拟请求状况
                if(b){
                    emitter.onNext(new Object());
                    emitter.onComplete();
                }else {
                    emitter.onError(new RuntimeException("no data"));
                }
            }
        }, BackpressureStrategy.BUFFER).subscribeOn(Schedulers.newThread())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Object>() {
            @Override
            public void accept(Object o) throws Exception {
                //TODO
            }
        }, new Consumer<Throwable>() {
            @Override
            public void accept(Throwable throwable) throws Exception {
                throwable.printStackTrace();
            }
        });
    }

代码很简单，就是模拟一个网络请求，如果正确调用onNext,onComplete，如果错误调用onError抛出一个错误，这个错误会被subscribe中的Consumer<Throwable>捕获。整个流程完全没有问题。

那么，我加上如下代码呢？

   public static void stopTest1(){
        if(mDisposable!=null && !mDisposable.isDisposed()){
            mDisposable.dispose();
        }
    }

这时候情况开始变得有些复杂。我们来捋一捋

情况1 我们在emitter抛出数据之后调用 stopTest1,并且接口返回正确(b = true)

情况2 我们在emitter抛出数据之后调用 stopTest1,并且接口返回正确(b = false)

以上两种情况是最长发生的，我们一直这样使用，并没有遇到问题。

情况3 我们在emitter抛出数据之前(也就是上面onComplete之前)调用 stopTest1,并且接口返回正确(b = true)

情况4 我们在emitter抛出数据之后(也就是上面onError之前)调用 stopTest1,并且接口返回正确(b = false)

对于情况三，同样没有问题。但是对于情况4，app竟然出现了crash

09-27 17:09:09.213 4395-4577/com.guardz.test E/AndroidRuntime: FATAL EXCEPTION: RxNewThreadScheduler-2
    Process: com.guardz.test, PID: 4395
    io.reactivex.exceptions.UndeliverableException: java.lang.RuntimeException: no data
        at io.reactivex.plugins.RxJavaPlugins.onError(RxJavaPlugins.java:366)
        at io.reactivex.internal.operators.flowable.FlowableCreate$BaseEmitter.onError(FlowableCreate.java:271)
        at com.guardz.test.Utils$3.subscribe(Utils.java:50)
        at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:72)
        at io.reactivex.Flowable.subscribe(Flowable.java:13234)
        at io.reactivex.Flowable.subscribe(Flowable.java:13180)
        at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
        at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
        at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

我们onError里面生成的错误直接被throw了出来。

原因分析

我们来看下当我们调用onError时做了什么。

首先Flowable.create会创建一个FlowableCreate对象，当我们调用subscribe 实际上是调用了subscribeActual，然后其中会进一步调用我create是传入的FlowableOnSubscribe对象的subscribe方法。（吐槽，真是绕啊，好多个subscribe!）

我们已backpressure（背压）为 BackpressureStrategy.BUFFER 作为例子。实际上就是

FlowableOnSubscribe.subscribe(new BufferAsyncEmitter<T>(...))

最终我们调用BufferAsyncEmitter的onError方法，相当于调用

public final void onError(Throwable e) {
            if (!tryOnError(e)) {
                RxJavaPlugins.onError(e);
            }
        }

        @Override
        public boolean tryOnError(Throwable e) {
            return error(e);
        }


protected boolean error(Throwable e) {
            if (e == null) {
                e = new NullPointerException("onError called with null. Null values are generally not allowed in 2.x operators and sources.");
            }
            if (isCancelled()) {
                return false;
            }
            try {
                actual.onError(e);
            } finally {
                serial.dispose();
            }
            return true;
        }

我们看到当isCancelled（实际上就是dispose之后）时return 了 false。于是就会进入RxJavaPlugins.onError(e)。

注：RxJavaPlugins 是一个Rxjava全局设置的config，可以在其中配置很多量。

    public static void onError(@NonNull Throwable error) {
        Consumer<? super Throwable> f = errorHandler;
        if (error == null) {
            error = new NullPointerException("onError called with null. Null values are generally not allowed in 2.x operators and sources.");
        } else {
            if (!isBug(error)) {
                error = new UndeliverableException(error);
            }
        }
        //检查是否设置了全局的错误处理方法。
        if (f != null) {
            try {
                f.accept(error);
                return;
            } catch (Throwable e) {
                // Exceptions.throwIfFatal(e); TODO decide
                e.printStackTrace(); // NOPMD
                uncaught(e);
            }
        }
        //如果没有 直接调用uncaught方法抛出不被捕获的错误。
        error.printStackTrace(); // NOPMD
        uncaught(error);
    }

至此，我们就能看到，当出现如上情况时，实际上调用的onError方法会直接抛出不被rxjava捕获的错误。

解决

解决方案有两个，第一种上面已经有了，我们可以主动配置RxJavaPlugins中的errorHandler用于全局捕获。但这并理想。

第二种方式就是不要手动调用onError方法，那么如何报错呢？我们可以通过onNext(null)来做报错。看下onNext方法

@Override
        public void onNext(T t) {
            if (done || isCancelled()) {
                return;
            }

            if (t == null) {
                onError(new NullPointerException("onNext called with null. Null values are generally not allowed in 2.x operators and sources."));
                return;
            }
            queue.offer(t);
            drain();
        }

当我们已经dispose，那么我们什么也不做，实际上不会调用subscribe中注册的onNext响应。这正是我们要的，因为我们dispose的目的不就是不再响应发送的数据吗？

如果没有被dispose，那么rxjava会代替我们调用onError方法抛出异常，也不需要我们操心。

外传

如果我简单改些一下上面的例子

public static void test1(){
        mDisposable = Flowable.create(new FlowableOnSubscribe<Object>() {
            @Override
            public void subscribe(FlowableEmitter<Object> emitter) throws Exception {
                //比如进行一个网络请求
               
                Thread.sleep(5000);
                
                boolean b = false; // 模拟请求状况
                if(b){
                    emitter.onNext(new Object());
                    emitter.onComplete();
                }else {
                    emitter.onError(new RuntimeException("no data"));
                }
            }
        }, BackpressureStrategy.BUFFER).subscribeOn(Schedulers.newThread())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Object>() {
            @Override
            public void accept(Object o) throws Exception {
                //TODO
            }
        }, new Consumer<Throwable>() {
            @Override
            public void accept(Throwable throwable) throws Exception {
                throwable.printStackTrace();
            }
        });
    }

Thread.sleep不再自己捕获错误。那么会发生上面情况。

我们来分析下，当我们调用dispose时，实际上我们会调用数据发送的线程的interrpter方法（详情可以参看subscribeOn这个方法），这个使用sleep就会被打断，并且抛出一个异常。

try {
            source.subscribe(emitter);
        } catch (Throwable ex) {
            Exceptions.throwIfFatal(ex);
            emitter.onError(ex);
        }

相当于source.subscribe抛出了异常，实际上还是会调用emitter.onError方法发射这个错误，这时候就回到了我们上面说的情况。

转载于:https://my.oschina.net/zzxzzg/blog/2209611