Non-IOException subtypes thrown from interceptor never notify Callback

A programming error in an interceptor or in OkHttp or an error of any kind will bypass the Callback and crash the Dispatcher thread leaving your consumer hanging forever. This was reported to Retrofit’s Kotlin coroutine support, but is not specific to it.

My proposal is for adding something like

default void onFailure(Call call, Throwable t) {
  if (t instanceof IOException) {
    onFailure(call, (IOException) t);
  }
}

and deprecating the existing onFailure callback in a 3.14.3 or 3.15 and the equivalent added to 4.0. This will force Retrofit onto Java 8, although given the added safety I think that’s acceptable.

[Tolriq]

+1000 😃 Tried a few times to ask for something allowing handling of non IOException errors and always rejected. Currently using added interceptor for that …

Typical use on Android would be security issues for rooted user who by default block Internet permission, not crashing and having the exception allows to properly notify the user.

    private class OkHttpExceptionInterceptor : Interceptor {

        @Throws(IOException::class)
        override fun intercept(chain: Interceptor.Chain): Response {
            try {
                return chain.proceed(chain.request())
            } catch (e: Throwable) {
                if (e is IOException) {
                    throw e
                } else {
                    throw IOException(e)
                }
            }
        }
    }

[danielesegato]

I don’t like the idea of a knob to change the behavior.

I was thinking more like a pluggable handling for the catch(Throwable) part with a default implementation.

I think I still prefer the default method approach as well.

I also liked it more.

Although given the change that was already made I have no idea if it can still be compatibly added.

the default implementation could just rethrow and an external catch would do exactly what it does now.

as an alternative you could add a new interface and just check for it and use it if available.

I don’t think there’s a clean way to make this kind of change in an API without breaking backward compatibility or requiring an extra step.