toBlocking（）のエラー処理

Question

私はRxJavaを使用して、アプリケーションをリアクティブパラダイムにリファクタリングしています。私は段階的にそれをやっているので、インタフェースを尊重するために、ある時点でtoBlocking()を使用する必要があります。 toBlocking()を使用してエラーを処理するにはどうすればよいですか？

public List<Employee> getEmployees() { 
    try { 
     return repository.getEmployees(); 
    } catch(Exception e) { 
     throw new MyCustomException(); 
    } 
} 

今、リポジトリは反応性のインタフェースを（Observable<List<Employee>>を返す）持っているので、私はこれをやっている：私はこのような何か持っていた、前

repository.getEmployees()に

public List<Employee> getEmployees() { 
    return repository.getEmployees().toBlocking().single(); 
} 

サブスクリプションのことエラーObservableを返します。私の質問です：どのように私はそれをブロックし続けるこのエラーを処理できますか？

私は方法singleOrDefault()を見つけましたが、singleOrThrow(new MyCustomException())のようなものはいいと思います。

Answer 1

あなたはそれを行うことができない、あなたは toBlocking()変換、try/catchブロックでそれをラップする必要がありますObservable、より多くの空想のコレクションのように、それは今で観測構成のパワーを正確に反応性ブロック欠けていますされていませんBlockingObservableへドキュメントを約BlockingObservableを述べたものを、事業者、スレッド/並列処理を制御し、エラー処理を内蔵している非同期APIの基本的な構築物、（onError()）

こと：

それはするのに役立ちますテストとデモ一般的に は生産アプリケーションには適していません（ブロックがBlockingObservableを使用する必要があると思われる場合は、これは通常、デザインを再考する ）。

したがって、ブロックすることで観察可能な点は何ですか？インターフェイスをObservableに変更できない場合は、RxとObservableを使用するすべての点が不足している可能性があります。理想的な場合は、システム内のすべてのイベントベースの処理を抽象化してから、演算子/合成/非同期を管理し、システム内のイベントストリームを構築します。
ObservableでAPI操作をラップし、それを非反応性の世界に戻すと、APIのコンシューマーは前述のRxのすべての利点を享受できません。
これを行う目的は何であるか再考すべきだと思います。最終目標は何ですか？システムのいくつかの場所で反応的アプローチに置き換えることを検討することができます。