RxJava2 mit retryWhen mit Filter

Question

Ich habe um mit retryWhen() Methode zu spielen, und ich bemerkte, dass, wenn Sie Filter verwenden() innerhalb retryWhen() und wenn filter() versagt gibt es keinen Rückruf ausgeführt nicht einmal onCompleted(). Kannst du mir bitte erklären, warum passiert das? Danke im Voraus.

Der Arbeits Fall:

Observable.error(new RuntimeException()) 
      .subscribeOn(Schedulers.io()) 
      .observeOn(AndroidSchedulers.mainThread()) 
      .retryWhen(errors -> errors 
        .filter(throwable -> throwable instanceof RuntimeException) 
        .zipWith(Observable.range(1, 3), (throwable, retryCount) -> { 
         Log.i("lol", "retry " + retryCount); 
         return retryCount; 
        })) 
      .subscribe(e -> Log.i("lol", "onNext"), throwable -> Log.i("lol", "onError"),() -> Log.i("lol", "onCompleted")); 

Die Arbeitsleistung:

I: retry 1 
I: retry 2 
I: retry 3 
I: onCompleted 

Aber wenn ich die Filter mit filter(throwable -> throwable instanceof IOException) verändern die beobachtbar ist wie in einem gefrorenen Zustand. Kein Rückruf ausgelöst.

Observable.error(new RuntimeException()) 
       .subscribeOn(Schedulers.io()) 
       .observeOn(AndroidSchedulers.mainThread()) 
       .retryWhen(errors -> errors 
         .filter(throwable -> throwable instanceof IOException) 
         .zipWith(Observable.range(1, 3), (throwable, retryCount) -> { 
          Log.i("lol", "retry " + retryCount); 
          return retryCount; 
         })) 
       .subscribe(e -> Log.i("lol", "onNext"), throwable -> Log.i("lol", "onError"),() -> Log.i("lol", "onCompleted")); 

Answer 1

Sie wollen nicht filter() innerhalb des retryWhen() Operator verwenden. Verwenden Sie stattdessen eine if Anweisung oder switch Anweisung, um sicherzustellen, dass Sie alle Fälle vollständig abdecken.

Die Art, wie retryWhen() funktioniert, ist, dass es ein Observable erstellt und die Funktion damit aufruft. Wenn es in seiner onError() Methode das Throwable fängt, sendet es das in das Observable hineinwerfbare und wartet auf das Ergebnis. Wenn es kein Ergebnis liefert, etwa wenn ein Throwable gefiltert wird, wird es ewig warten.