filmov
tv
Angular httpclient error handling
Показать описание
In this video we will discuss error handling in Angular. When using HttpClient, to call a server side service, errors may occur. When they do occur we want to handle these errors.
Text version of the video
Healthy diet is very important for both body and mind. We want to inspire you to cook and eat healthy. If you like Aarvi Kitchen recipes, please support by sharing, subscribing and liking.
Slides
Angular CRUD Tutorial
Angular CRUD Tutorial Text Articles & Slides
All Dot Net and SQL Server Tutorials in English
All Dot Net and SQL Server Tutorials in Arabic
When an Angular component needs data, there are usually 3 players
1. The Component itself
2. The Angular Service and
3. The Server Side Service
The first question that comes to our mind is, should we handle the service related errors in the service itself or in the component that consumes the service. According to Angular style guide, error inspection, interpretation, and resolution is something you want to do in the service, not in the component.
If all goes well the server side service provides data to the client side angular service and the Angular service provides it to the component, which then displays that data to the user.
However, sometimes the request may fail on the server or on the client. There are two types of errors that can occur.
The server may reject the request, returning an HTTP response with a status code such as 404 or 500. These are error responses.
Something could go wrong on the client-side such as a network error that prevents the request from completing successfully or an exception thrown in an RxJS operator. These errors produce JavaScript ErrorEvent objects.
The HttpClient captures both kinds of errors in its HttpErrorResponse and you can inspect that response to figure out what really happened.
So, the important point to keep in mind is, if the HttpErrorResponse is an instance of ErrorEvent, then it means that a client-side or network error occurred. If it's not an instance of ErrorEvent, then it means a server error occured.
Displaying the actual raw errors to the end user is bad for two reasons - First they are cryptic and does not make much sense to the end user and second they may contain sensitive information that could be useful for a potential hacker. That is why we are logging the actual error and returning a user friendly error message.
Finally, take the Observables returned by the HttpClient methods and pipe them through to the error handler.
With the release of rxjs version 5.5, we have Pipeable Operators that can be used along with the pipe() function. Before the introduction of pipeable operators, we used to chain operators as shown below.
So the point that I am, trying to make is
1. There are 2 types of operators in rxjs - Pipeable Operators and Patch Operators
2. Pipeable Operators are imported from rxjs/operators/
3. Patch Operators are imported from rxjs/add/operator/
4. Pipeable Operators have several benefits over Patch Operators. So if you have rxjs version 5.5 or later use pipeable operators.
5. Use the following link to read the benefits of pipeable operators
In our case, the angular service getEmployees() method is consumed by a Resolver service, and this resolver service provides the data to the LIST route. If there is an exception, the resolver fails and the target route, in our case the LIST route will not be activated. If a component is directly consuming the angular service getEmployees() method, then it is easy to catch the error observable and display the error message to the user.
However, when a resolver is involved, the target route is not activated if there is an error. So displaying an error message to the end user is a bit more involved.
In our next video, we will discuss handling errors and displaying error messages where there is a resolver between an angular service and the component.
Text version of the video
Healthy diet is very important for both body and mind. We want to inspire you to cook and eat healthy. If you like Aarvi Kitchen recipes, please support by sharing, subscribing and liking.
Slides
Angular CRUD Tutorial
Angular CRUD Tutorial Text Articles & Slides
All Dot Net and SQL Server Tutorials in English
All Dot Net and SQL Server Tutorials in Arabic
When an Angular component needs data, there are usually 3 players
1. The Component itself
2. The Angular Service and
3. The Server Side Service
The first question that comes to our mind is, should we handle the service related errors in the service itself or in the component that consumes the service. According to Angular style guide, error inspection, interpretation, and resolution is something you want to do in the service, not in the component.
If all goes well the server side service provides data to the client side angular service and the Angular service provides it to the component, which then displays that data to the user.
However, sometimes the request may fail on the server or on the client. There are two types of errors that can occur.
The server may reject the request, returning an HTTP response with a status code such as 404 or 500. These are error responses.
Something could go wrong on the client-side such as a network error that prevents the request from completing successfully or an exception thrown in an RxJS operator. These errors produce JavaScript ErrorEvent objects.
The HttpClient captures both kinds of errors in its HttpErrorResponse and you can inspect that response to figure out what really happened.
So, the important point to keep in mind is, if the HttpErrorResponse is an instance of ErrorEvent, then it means that a client-side or network error occurred. If it's not an instance of ErrorEvent, then it means a server error occured.
Displaying the actual raw errors to the end user is bad for two reasons - First they are cryptic and does not make much sense to the end user and second they may contain sensitive information that could be useful for a potential hacker. That is why we are logging the actual error and returning a user friendly error message.
Finally, take the Observables returned by the HttpClient methods and pipe them through to the error handler.
With the release of rxjs version 5.5, we have Pipeable Operators that can be used along with the pipe() function. Before the introduction of pipeable operators, we used to chain operators as shown below.
So the point that I am, trying to make is
1. There are 2 types of operators in rxjs - Pipeable Operators and Patch Operators
2. Pipeable Operators are imported from rxjs/operators/
3. Patch Operators are imported from rxjs/add/operator/
4. Pipeable Operators have several benefits over Patch Operators. So if you have rxjs version 5.5 or later use pipeable operators.
5. Use the following link to read the benefits of pipeable operators
In our case, the angular service getEmployees() method is consumed by a Resolver service, and this resolver service provides the data to the LIST route. If there is an exception, the resolver fails and the target route, in our case the LIST route will not be activated. If a component is directly consuming the angular service getEmployees() method, then it is easy to catch the error observable and display the error message to the user.
However, when a resolver is involved, the target route is not activated if there is an error. So displaying an error message to the end user is a bit more involved.
In our next video, we will discuss handling errors and displaying error messages where there is a resolver between an angular service and the component.
Комментарии