Handling Errors
As powerful as observables are, they can’t prevent errors from happening. Instead, they provide a concrete way to gracefully handle errors as they arise. Errors are handled in the subscribe call (same as regular data). So far, the examples have only passed a single parameter to .subscribe—a function that runs for every datum that arrives at the end of the stream. Turns out, a total of three parameters can be passed in (the latter two being optional):
| | .subscribe( |
| | function next(val) { /* A new value has arrived */ }, |
| | function error(err) { /* An error occured */ }, |
| | function done() { /* The observable is done */ } |
| | ); |
The first (the one you’ve been using until this point) is known as the next function. It’s called on every new value passed down the observable—this is the option you’ve been using. The second, error, is called when an error occurs at some point in the observable stream. Once an error happens, no further data is sent down the observable and the root unsubscribe functions are called. The observable is considered to be in an “error” state (much like promises) and needs to be resubscribed to get any more data (later in this chapter, you’ll learn how to do that with the retry operator). Finally, the done function is called when the observable finishes. Not all observables will finish—fromEvent is an example of such an infinite observable. For finite observables (like the inner observable created in Chapter 2, Manipulating Streams), done is an important thing to know about. While it’s possible to handle all three cases by passing in each function as a separate argument to subscribe, the following single-argument example is also valid:
| | .subscribe({ |
| | next: val => { /* A new value has arrived */}, |
| | err: err => { /* An error occured */}, |
| | done: () => { /* The observable is done */} |
| | }); |
As we covered in Chapter 1, Creating Observables, you’ll notice that this object also qualifies as an observer. Any valid observer can be passed directly into .subscribe. Technically, none of the properties are mandatory. If you had a large pile of data to process but only cared that the processing was done, you could pass in an object with only the done property. Strictly speaking, it’s valid to pass an empty object to .subscribe, but it’s not very useful. When you reach Chapter 5, Multiplexing Observables, you’ll find some advanced RxJS classes, which are observers in addition to being observables.
Most of the time engineers just use the simpler non-observer version unless there’s a reason to skip the next or error functions, such as when a function needs to send a value to a server, but doesn’t care about the return data.
Now, let’s go back to that earlier AJAX example and add some error handling.
| | ajax('/api/managingAsync/ajaxExample') |
| | .subscribe( |
| | result => console.log(result), |
| | err => alert(err.message) |
| | ); |
Now that a clear error message is presented, we can diagnose the problem immediately—the route that is being requested does not exist. If this was a user-facing page, you could use the error handler to display relevant information to the user. In this case, it’s a quick fix to update the URL the request is sent to:
| | ajax('/api/managingAsync/correctAjaxExample') |
| | .subscribe( |
| | result => console.log(result), |
| | err => alert(err.message) |
| | ); |