2015-11-05 9 views
5

chcę osiągnąć, że jeśli zgłoszę metodę Obervable.subscribe(Action1), nie rzucać OnErrorNotImplementedException wszędzie, ale jeśli zgłoszę Obervable.subscribe(Action1, Action1), druga akcja jest wywoływana, gdy błąd jest podnoszona jako normalne. Próbowałem na dwa sposoby:Prevent OnErrorNotImplementedException

.onErrorResumeNext(Observable.empty()) 

OnErrorNotImplementedException ten sposób nie jest wyrzucane, jednak jeśli mijam również drugie działanie, akcja nie jest wywoływana albo.

drugie:

.lift(new Observable.Operator<T, T>() { 
    @Override 
    public Subscriber<? super T> call(Subscriber<? super T> subscriber) { 
     return new Subscriber<T>() { 
      @Override 
      public void onCompleted() { 
       if (!subscriber.isUnsubscribed()) { 
        subscriber.onCompleted(); 
       } 
      } 

      @Override 
      public void onError(Throwable e) { 
       if (!subscriber.isUnsubscribed()) { 
        try { 
         subscriber.onError(e); 
        } catch (Throwable t) { 
         if (!(t instanceof OnErrorNotImplementedException)) { 
          throw t; 
         } 
        } 
       } 
      } 

      @Override 
      public void onNext(T t) { 
       if (!isUnsubscribed()) { 
        subscriber.onNext(t); 
       } 
      } 
     }; 
    } 
}); 

Problem polega na tym, czy observeOn() nazywa później to będzie to asynchroniczny i oczywiście mój wyjątek obsługi tutaj nie zadziała.

Czy można to osiągnąć. Szkoda, że ​​nie byłoby metody subscribe(), która nie rzuca OnErrorNotImplementedException w onError.

Odpowiedz

8

Oto jak to robimy w pracy. Zamiast wykonywać działania, stworzyliśmy abstrakcyjnego NYTSubscribera, który ma implementację onError i onCompleted. W ten sposób można korzystać z tego abonenta i tylko wdrożyć zwrotnego onNext czy można zastąpić onError i onCompleted gdy konieczne

public abstract class NYTSubscriber<T> extends Subscriber<T> { 

@Override 
public void onCompleted() { 
} 

@Override 
public void onError(Throwable e) { 
} 
} 
+1

Dzięki! Tak, to jest sposób. Mój problem polega na tym, że w ten sposób tracę składnię lambda w subskrybencie i zawsze muszę dodawać klasy anonimowe. :( – WonderCsabo

+0

Wygląda na to, że nie ma innej możliwości niż przekazanie pustej implementacji 'onError()' z lambda lub podklasą, więc akceptuję tę odpowiedź: – WonderCsabo

+0

Sprawdź moje rozwiązanie poniżej @WonderCsabo – FireZenk

8

Oto kolejna z możliwych rozwiązań, można zdefiniować onNext i Throwable (również nie można stracić lambda składnia):

.subscribe(t -> doSomething(t), e -> showError(e)); 
+1

Dzięki! Cóż, moim zamiarem było nie dodawanie manekin onError wszędzie, ale ponieważ nie ma innego rozwiązania, robię teraz. – WonderCsabo

0

jeśli nie podoba „.onErrorResumeNext (Observable.empty())” strumienia zostanie ukończone, gdy wystąpi błąd - dlatego twoje działania nie jest tzw. Możesz użyć ".retry()", a twój strumień zostanie automatycznie uruchomiony ponownie, gdy wystąpi błąd.