How to handle various types of errors in Retrofit Rx onError without an ugly instance

Question

I would like to know your ways of handling various errors (for example, HTTP exceptions, exceptions for connecting to the Internet, etc.) in modifying Rx onError without using instanceof , as suggested here: How to handle network errors in Retrofit 2 using RxJava or here: Handle errors in Retrofit 2 RX

In kotlin, I'll just do some extension functions for each type of throw, to do whatever I want.

But I am forced to use Java in the project. Any good suggestions?

is an approach to creating some kind of error handler as follows:

 public interface ErrorHandler { void handleError(Exception e); void handleError(HttpException e); void handleError(NullPointerException npe); } 

OK? I know that this does not happen because every time I need to handle another specific error, I have to change the interface, so this is a violation of the Open Close principle. But I can not find a solution.

amuses Wojtek

Answer 1

The compiler determines which method to invoke, not the virtual machine. Thus, the class that you described will not solve the problem unless you check instanceof first and pass the parameter the correct type. Otherwise, you will get a handleError (exception e) every time.

But I didn’t want to create an answer for this reason, but to assert that in many cases only one error handler is preferable, and not responsibility. Often in java we find ourselves in terrible situations like:

  catch (NoSuchAlgorithmException e) { throw new IllegalStateException("No such algorithm: RSA?", e); } catch (NoSuchProviderException e) { throw new IllegalStateException("No such provider: " + ANDROID_KEYSTORE_ID, e); } catch (InvalidAlgorithmParameterException e) { throw new IllegalStateException("Bug setting up encryption key for user credentials: ", e); } catch (KeyStoreException e) { throw new IllegalStateException("Bug setting up encryption key for user credentials: ", e); } catch (IOException e) { Log.w(TAG, "Exception setting up keystore for user creds. They won't be stored.", e); } catch (CertificateException e) { Log.w(TAG, "Exception setting up keystore for user creds. They won't be stored.", e); } 

Having only one error handler allows us to combine many types of exceptions together. You can see in this code, there are exceptions that should never be thrown, exceptions that can only be the result of errors in the code, and legitimate exceptional conditions that we need to handle. I find this messy and prefer to say:

 if (e instanceof NoSuchAlgorithmException || e instanceof NoSuchProviderException) { Log.wtf(TAG, "What the heck is this?", e); throw new IllegalStateException("This is some kind of weird bug", e); } else if (e instanceof IOException || e instanceof CertificateException) { // This can happen sometimes, track event in analytics and perhaps // try some alternative means of credential storage. } else { // At least here the app won't crash if some unexpected exception occurs, // since we're trapping everything. } 

I don’t think it’s so bad that you can combine unexpected crashes together and handle them in a more user-friendly way than crashing the application. Even if this is just a mistake, it’s better to track it in your analytic structure behind the scenes than the user's bomb from the application. So many crashes in Android applications are actually fully repaired, but we don’t go around catching Throwable in every try / catch statement because it has a lot of extra code.

Answer 2

The right way to OOP to avoid chained if or catch es is polymorphism. You can define several custom exception classes that display a common interface, which are enough to handle one handler.

Suppose you need to divide errors into two groups: recoverable and not recoverable. Then your base exception class (or interface) should have an abstract isRecoverable() method, which you override in each subclass. Then in your handler there will be only one if : if (e.isRecoverable()) { ... } else { ... } .

The disadvantage is that you have to wrap all the standard exceptions in your own in the places where they were selected (you have to catch them).

The right choice will largely depend on your task.