Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

186
Views
Error handling in toBlocking()

I'm refactoring an app to reactive paradigm using RxJava. I'm doing it step by step so I need to use toBlocking() in some cases in order to respect the interfaces, for the moment. How can I handle an error when use toBlocking()?

Before, I had something like this:

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

Now, the repository has a reactive interface (returns Observable<List<Employee>>), so I'm doing this:

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

Subscription to repository.getEmployees() may return an error Observable. My question is: how can I handle this error keeping it blocking?

I have found out a method singleOrDefault(), but something like singleOrThrow(new MyCustomException()) would be nice.

about 4 years ago · Santiago Trujillo
3 answers
Answer question

0

You can't do that, you will need to wrap it with try/catch block, toBlocking() transform the Observable to BlockingObservable which is not exactly reactive block, more like fancy collection, it's now lack the power of composing Observables, operators, controlling the thread/parallelism, and the basic construct of async API, which has error handling built in, (onError())

That what the docs stated about BlockingObservable:

It can be useful for testing and demo purposes, but is generally inappropriate for production applications (if you think you need to use a BlockingObservable this is usually a sign that you should rethink your design).

So, what is the point to act with blocking observable? if you can't change the interface to Observable, then you probably missing all the point of using Rx and Observable, which is (at ideal) to abstract out every event based operation in the system, and then being able to use the power of Operators/Composition/Async management and construct event streams in your system.
If you just wrap some API operation with Observable and then return it back to non-reactive world, then the consumer of the API can't enjoy all the aforementioned benefits of Rx.
So, I think you should reconsider what is the purpose of doing that, and what is your final goal, you can consider replacing to Reactive approach in few places in your system for start.

about 4 years ago · Santiago Trujillo Report

0

We have another option to handler error by using variant method to handle error as onErrorReturn ...

public List<Employee> getEmployees() {
    return repository.getEmployees().onErrorReturn{
       //Do something 
       //Then return value in case error happened
    }.toBlocking().single(); 
}
about 4 years ago · Santiago Trujillo Report

0

Your MyCustomException is wrapped in RuntimeException by Rx, so you should catch RuntimeException then call getCuase() to get MyCustomException like below.

public List<Employee> getEmployees() {
    try {
        return repository.getEmployees().toBlocking().single(); 
    } catch (RuntimeException e) {
        MyCustomException myCustomException = e.getCause();
        if (e != null) {
            // caught MyCustomException
        }
    }
}
about 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!