search

jgilfelt / chuck

An in-app HTTP inspector for Android OkHttp clients
Apache License 2.0
4.68k stars 452 forks source link

Don't throw exception for canceled calls in release mode #61

Open MKevin3 opened 6 years ago

MKevin3 commented 6 years ago

When I build in release mode and I cancel an OKHTTP call I get an exception as shown below.

The chuck.readystatesoftware.com.ChuckInterceptor.intercept should be full NO-OP but it is catching canceled calls and reporting them as IOExceptions. I turn around and catch those but I should not have to as I am already processing the isCanceled method on the original call.

    at http.internal.okhttp3.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:114)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at chuck.readystatesoftware.com.ChuckInterceptor.intercept(ChuckInterceptor.java:56)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at logging.okhttp3.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:145)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at http.internal.okhttp3.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
    at okhttp3.RealCall.execute(RealCall.java:69)
    at retrofit2.OkHttpCall.execute(OkHttpCall.java:180)
    at retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall.execute(ExecutorCallAdapterFactory.java:91)
    at activity.bless.lularoe.com.OpenOrdersActivity$requestOrders$1.call(166)
    at activity.bless.lularoe.com.OpenOrdersActivity$requestOrders$1.call(37)
    at flowable.operators.internal.reactivex.io.FlowableFromCallable.subscribeActual(FlowableFromCallable.java:37)
    at reactivex.io.Flowable.subscribe(Flowable.java:12995)
    at reactivex.io.Flowable.subscribe(Flowable.java:12941)
    at flowable.operators.internal.reactivex.io.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
    at schedulers.internal.reactivex.io.ScheduledRunnable.run(ScheduledRunnable.java:61)
    at schedulers.internal.reactivex.io.ScheduledRunnable.call(ScheduledRunnable.java:52)
    at concurrent.util.java.FutureTask.run(FutureTask.java:237)
    at concurrent.util.java.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:272)
    at concurrent.util.java.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
    at concurrent.util.java.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
    at lang.java.Thread.run(Thread.java:762)
autonomousapps commented 6 years ago

I don't even add chuck as an interceptor unless I'm in debug mode. Why are you using it for release builds?

MKevin3 commented 6 years ago

I thought the goal of 

    debugImplementation 'com.readystatesoftware.chuck:library:1.1.0'
    releaseImplementation 'com.readystatesoftware.chuck:library-no-op:1.1.0'

Was to allow you to avoid this extra step

        // Only add Chuck support for debug builds - its no-op mode is not perfect
        @Suppress("ConstantConditionIf")
        if (BuildConfig.DEBUG_MODE) {
            builder.addInterceptor(ChuckInterceptor(App.instance))
        }

It appears the no-op version is just to keep code size down, not to fully stop operation. I have everything working as I want with the extra code step shown above. Just did not think I was going to need to do it.