One idea I have is:

• When observe is called and an exception happens, absorb the exception and pass it down to the Observable returned in observe.

• When refresh is called and an exception happens, absorb the exception and pass it to the Observable returned in refresh.

Pros:

• Exception is received by the developer.
• No changes to the API.

Cons:

• If Teller has a bug, an exception is raised, it will be passed down to the developer.

Great place to start: OnlineRepository, exception thrown in fetch call.

Good way to test this is to go into OnlineRepositoryIntegrationTest, create a test similar to the first fetch success or fail tests but instead of onNext(...), pass in onError().

Another idea:

Ignore Rx completely. Wrap each call to an abstract function of LocalRepository and OnlineRepository in a try/catch block. If an exception is raised, throw it with a message such as "Teller detected an exception in your ___() function" to help.

The nice part about this is to also help with Teller exception handling (when Teller code throws an exception from a bug). When a dev calls a function on Teller code, we can wrap the Teller code in a try/catch block. When an exception is thrown, we can show a message such as "An exception has been thrown within Teller. This is probably a bug. Report that here: github.com/teller/issues/new and paste the below information:....." where the user can give we need to fix it. Exceptions on the dev's code should not interfere because of nested try/catch blocks surrounding dev's code.

This issue couples well with the above paragraph. Debug statements can be generated and saved by Teller and dumped to the console when an exception happens.

iOS has this implemented with a try/catch implementation. See code