To handle errors effectively, it's essential to understand the types of errors that can occur. Let’s start by categorizing the errors you might encounter.
Various types of errors can occur. However, these errors can generally be classified into two categories:
Let’s categorize the errors we’ve discussed into these classifications.
Errors received from server APIs with clear status codes can be considered Expected Errors because they can be anticipated and addressed in advance.
For example, errors such as unauthorized access (401) or forbidden access (403) can be handled appropriately based on the situation. It is also common to define more detailed error codes for each status code to manage application logic in response to errors. These are referred to as Expected Errors.
On the other hand, server errors in the 500 range are classified as Unexpected Errors because they are unpredictable. Situations where the server cannot respond for any reason can occur at any time. Additionally, errors that might arise due to the user’s network environment or browser environment are difficult to predict and are thus classified as Unexpected Errors.
Errors can also be classified based on the interaction with the user, rather than just the environment. One way to categorize errors is by considering whether the user can do something about the error. Here are the criteria for this classification:
For instance, authentication or authorization errors fall into this category. A user who is not logged in might encounter a 401 status error. In this case, you can provide a login screen or display a message indicating that login is required.
If a user does not have permission to access a specific screen, you can guide them to request access from an administrator.
No product developer welcomes user abandonment. It is essential to provide guidance to users who encounter errors to help them overcome the situation. For example, providing a refresh button for temporary network errors or a button to navigate back to the previous screen when accessing a non-existent page.
However, there are cases where informing the user of the error situation does not help at all. For instance, if the code includes components that do not work on low-spec devices or browsers, the user cannot do anything about it. (Perhaps a message suggesting the use of a different browser?)
Both cases, 1 and 2, involve providing a message. The difference is that case 1 includes some action or guidance that prompts the user to take steps.
Is the encountered error something the user can resolve on their own, or not?
So, how should we handle errors that occur? What kind of interface should the application provide to the user when an error happens? Let's explore how to address different types of errors based on their characteristics.
A typical example is a network error. These can occur at any time depending on the user's network environment. The simplest solution is to inform the user that it is a 'temporary error' and provide guidance to retry the previous action.
For these errors, it’s crucial to ensure that the application as a whole is not adversely affected. For instance, if an application calls 10 APIs on one screen, failing one should not trigger an error message across the entire application and require a retry of all calls.
Instead, focus on recovering only the area that failed.
These are errors that are difficult to anticipate and have no straightforward resolution. Such errors should be minimized during development, and there should be a plan for handling them when they occur. Since users cannot resolve these errors themselves, providing an easy way to contact customer support might be necessary.
Errors outside the developer's control should be monitored using tools like Sentry. These errors need to be fixed to prevent users from encountering them. Additionally, ensure there is a mechanism for users to return to the application if they do encounter such errors.
These are known errors for which there is no resolution available to the user. If users cannot resolve them on their own, it indicates a missed opportunity for error handling. If users intentionally perform abnormal actions, it could be a sign of a security vulnerability.
These errors occur when there is malicious intent to exploit the application. They typically stem from security vulnerabilities and should be prevented during development. It is crucial to address basic security concerns such as CORS and XSS and collaborate with the security team to build a secure application.
These errors are usually part of the business logic that developers are already aware of:
In these cases, provide appropriate guidance within the application or create separate pages to direct users.
Users should clearly understand what to do next after encountering an error message. This helps reduce the frequency of errors and prevents user abandonment. Therefore, alongside the error message, it is essential to include a call to action.
For example, if there is a field validation error, focus on the field where the error occurred. If the user navigated to a non-existent page, provide a button to go back to the previous screen.
We explored error handling. Let's efficiently manage errors by utilizing various tools and technologies such as error monitoring tools and React's ErrorBoundary, which can catch errors within a limited scope.
The above is the detailed content of Client-Centered Error Handling. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
