Client-Centered Error Handling

Understanding and Handling Errors

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.

Types of Errors in a Web Client Environment

Network Errors

• Connection Issues: Problems with establishing a connection to the server.
• Timeouts: Requests taking too long to receive a response.
• DNS Errors: Issues with domain name resolution.
• HTTP Errors: Errors such as 404 Not Found, 500 Internal Server Error, etc.

Server API Errors

• Invalid Responses: Unexpected or malformed data from the server.
• Authentication Errors: Issues with user authentication or authorization.
• Rate Limiting: Restrictions due to exceeding API usage limits.

User Browser Environment Errors

• Browser Compatibility: Issues arising from differences in how browsers handle certain features.
• JavaScript Errors: Errors in the client-side JavaScript code.
• Resource Loading Errors: Problems loading resources like images, scripts, or stylesheets.

Other Errors

• Client-Side Errors: Errors related to the user's device or operating system.
• UI/UX Errors: Issues with the user interface or user experience, such as broken links or incorrect layout.

Various types of errors can occur. However, these errors can generally be classified into two categories:

1. Expected Errors: Errors where the occurrence and nature are known in advance.
2. Unexpected Errors: Errors where the occurrence and nature are not known in advance.

Let’s categorize the errors we’ve discussed into these classifications.

Can the error be anticipated or not?

Expected Errors

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.

Unexpected 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.

User and Error

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:

1. Errors that the user can understand and resolve (Errors that help the user continue using the application).
2. Errors that the user cannot resolve (Errors that provide no assistance to the user).

Resolvable Errors

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.

Unresolvable Errors

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?

How to Handle Errors

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.

Unpredictable but Solvable Errors

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.

Error range

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.

Unpredictable and Unsolvable Errors

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.

Monitoring

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.

Predictable but Unresolvable 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.

Security-Related Errors

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.

Predictable and Solvable Errors

These errors are usually part of the business logic that developers are already aware of:

• 401 Unauthorized Error: Requires login.
• 404 Not Found Error: Accessing a wrong page.
• Other business logic errors: Defined by the application’s logic.

In these cases, provide appropriate guidance within the application or create separate pages to direct users.

Importance of Guidance

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.

Conclusion

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!