When communicating with some backend API, data travels over the network using the HTTP protocol. As such, failures may occur, be it on our own device (i.e. the browser) or on the server-side which may not be available or unable to process our request. We need to handle such error responses and give the user a proper feedback.
So I have here a very simple application. We have here an app component, which internally uses here a people service which gets invoked here. The people service has a fetch people method which executes an HTTP call using here the HTTP client which comes from the Angular common HTTP package.
Now since this a call that goes via the HTTP protocol, obviously there can be errors while we are going to fetch that data. Those errors can be either local or also remote,mostly because the server returns some error code.
Let's simulate this behavior by here simply copying the URL and here entering URL that doesn't exist. Let's save. If I click now that button, as you can see, nothing happens which leads to bad user experience because user doesn't know what happened behind the scenes. If we open up the network panel here of Chrome, we obviously can see how the requests gets executed to the server, and the server returns us a 404 status code which means not found.
In a well-crafted application, we obviously want to show some notification to the user. What we can do here is to basically leverage a parameter which is a callback method of our subscribe function here. So when the first parameter here is being invoked in the case of success, the second parameter gets invoked whenever an error happens.
Here we get an HTTP error response which we should here import from the Angular common HTTP package. Then we implement here that callback. Here we can say whenever basically that error is an instance of error, the error object, then this is a client side error.
We obviously want to display something to the user. Let's say we have a local variable message. Here we basically say, "An error occurred." We can also include some more information from that error object which we can access here via that error.error object and the message property.
Similarly, in the case when the error is not local, but returned from the server, we can here again set that message property and say backend returned error code. We can get here the status of our HTTP request, which we can access via that error.status property.
Maybe there's also some useful message in the body. So we could say body was error.message. Now obviously that message variable doesn't exist yet, so let's quickly add it here. We also need to go to our HTML part of our component and here, for sake of simplicity, we could simply do something like an ng-if whenever that message is set. Say something like error, and here we display the message to the user. Great.
Let's try it now. As you can see, in the case of an error, whenever that error happens, we get the message printed out as we specified here in our error callback. Probably in the success call, if we set that message to now and let's also go to the people service and reactivate our successful callback just to see that works again. As you can see, the data arrives, just as we expect...
Under what circumstances client side error message is set? Both 4xx and 5xx errors are handled by backend error message.
These errors happen when the HTTP request doesn't even start. It's mainly to distinguish between errors coming from the server like 4xx and 5xx as you correctly said and those that might happen before or when invoking the http client.
It is interesting how you infer if error is local or coming from backend, by checking if errr is instance of Error. Is this so by design ?
yeah basically if you set a breakpoint in the catch block, you can see those errors happening client-side before going through the network, come up as "Error" instance :)