Skip to content

Commit 753d121

Browse files
committed
Update 3. Advanced error handling.md
1 parent 5de2228 commit 753d121

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

Part 3 - Taming the sequence/3. Advanced error handling.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Advance error handling
22

3-
We've already seen how we can handle an error in the observer. However, by that time, we are practically ourside of the monad. There can be many kinds of errors and not every error is worth pushing all the way to the top. In standard Java, you can catch an exception at any level and decide if you want to handle it there or throw it further. Similarily in Rx, you can define behaviour based on errors without terminating the observable and forcing the observer to deal with everything.
3+
We've already seen how we can handle an error in the observer. However, by that time, we are practically outside of the monad. There can be many kinds of errors and not every error is worth pushing all the way to the top. In standard Java, you can catch an exception at any level and decide if you want to handle it there or throw it further. Similarly in Rx, you can define behaviour based on errors without terminating the observable and forcing the observer to deal with everything.
44

55
## Resume
66

@@ -43,7 +43,7 @@ public final Observable<T> onErrorResumeNext(
4343

4444
![](https://raw.github.com/wiki/ReactiveX/RxJava/images/rx-operators/onErrorResumeNext.png)
4545

46-
The first overload uses the same followup observable in every case. The second overload allows you to decide what the resume sequence should be based on the error that occured.
46+
The first overload uses the same followup observable in every case. The second overload allows you to decide what the resume sequence should be based on the error that occurred.
4747

4848
```java
4949
Observable<Integer> values = Observable.create(o -> {
@@ -64,7 +64,7 @@ with onError: 2147483647
6464
with onError: Completed
6565
```
6666

67-
There's nothing stopping the resumeSequence from failing as well. In fact, if you wanted to change the type of the error, you can return an observable that fails immediatelly. In standard Java, components may decide they can't handle an error and that they should re-throw it. In such cases, it is common wrap a new exception around the original error, thus providing additional context. You can do the same in Rx:
67+
There's nothing stopping the resumeSequence from failing as well. In fact, if you wanted to change the type of the error, you can return an observable that fails immediately. In standard Java, components may decide they can't handle an error and that they should re-throw it. In such cases, it is common wrap a new exception around the original error, thus providing additional context. You can do the same in Rx:
6868

6969
```java
7070
.onErrorResumeNext(e -> Observable.error(new UnsupportedOperationException(e)))
@@ -99,7 +99,7 @@ public final Observable<T> retry(long count)
9999
```
100100
![](https://raw.github.com/wiki/ReactiveX/RxJava/images/rx-operators/retry.png)
101101

102-
If the error doesn't go away, `retry()` will lock us in an infinite loop of retries. The second overload limits the number of retries. If errors persist and the sequence fails n times, `retry(n)` will fail too. Lets see this in an example
102+
If the error doesn't go away, `retry()` will lock us in an infinite loop of retries. The second overload limits the number of retries. If errors persist and the sequence fails n times, `retry(n)` will fail too. Let's see this in an example
103103

104104
```java
105105
Random random = new Random();
@@ -122,7 +122,7 @@ values
122122
java.lang.Exception
123123
```
124124

125-
Here. we've specified that we want to retry once. Our observable fails after two values, then tries again, fails again. The second time it fails the exception is allowed through.
125+
Here we've specified that we want to retry once. Our observable fails after two values, then tries again, fails again. The second time it fails the exception is allowed pass through.
126126

127127
In this example, we have done something naughty: we have made our subscription stateful to demonstrate that the observable is restarted from the source: it produced different values the second time around. `retry` does not cache any elements like `replay`, nor would it make sense to do so. Retrying makes sense only if there are side effects, or if the observable is [hot](/Part%203%20-%20Taming%20the%20sequence/6.%20Hot%20and%20Cold%20observables.md).
128128

@@ -169,11 +169,11 @@ TimeInterval [intervalInMilliseconds=103, value=1]
169169
TimeInterval [intervalInMilliseconds=0, value=2]
170170
```
171171

172-
Our source observable emits 2 values and immediately fails. When that happens, the observable of failures inside `retryWhen` emits the error. We delay that emission by 100ms and send it back to signal a retry. `take(2)` guarantees that our signaling observabe will terminate after we receive two errors. `retryWhen` sees the termination and doesn't retry after the second failures.
172+
Our source observable emits 2 values and immediately fails. When that happens, the observable of failures inside `retryWhen` emits the error. We delay that emission by 100ms and send it back to signal a retry. `take(2)` guarantees that our signaling observable will terminate after we receive two errors. `retryWhen` sees the termination and doesn't retry after the second failures.
173173

174174
## using
175175

176-
The `using` operator is for creating observables from resources that need to managed. It guarantees that your resources will be managed regardless of when and how subscriptions are terminated. If you were to just use `create`, you would have to do the managing in the traditional Java paradigm and inject it into Rx. `using` is a more natural way of managing resources in Rx.
176+
The `using` operator is for creating observables from resources that need to be managed. It guarantees that your resources will be managed regardless of when and how subscriptions are terminated. If you were to just use `create`, you would have to do the managing in the traditional Java paradigm and inject it into Rx. `using` is a more natural way of managing resources in Rx.
177177

178178
```java
179179
public static final <T,Resource> Observable<T> using(
@@ -223,9 +223,9 @@ e
223223
Disposed: MyResource
224224
```
225225

226-
When we subscribe to `values`, the resource factory function is called which returns `"MyResource"`. That string is used to produce an observable which emits all of the characters in the string. Once the subscription ends, the resource is disposed of. A `String` doesn't need any more managing than what the garbage collector will do. Resources may actually need such managing include listening on ports, database connections, opened files etc.
226+
When we subscribe to `values`, the resource factory function is called which returns `"MyResource"`. That string is used to produce an observable which emits all of the characters in the string. Once the subscription ends, the resource is disposed of. A `String` doesn't need any more managing than what the garbage collector will do. Resources may actually need such managing, e.g., database connections, opened files etc.
227227

228-
It is important to note here that we are responsible for terminating the observable, just like we were when using the `create` method. With `create`, terminating is a matter of schemantics. With `using`, not terminating defeats the point of using it in the first place. Only upon termination will the resources be released. If we had not called `o.onCompleted()`, the sequence would be assumed to be still active and needing its resources.
228+
It is important to note here that we are responsible for terminating the observable, just like we were when using the `create` method. With `create`, terminating is a matter of semantics. With `using`, not terminating defeats the point of using it in the first place. Only upon termination the resources will be released. If we had not called `o.onCompleted()`, the sequence would be assumed to be still active and needing its resources.
229229

230230

231231

0 commit comments

Comments
 (0)