Web front-end network concurrent request same error processing method and system
By using error information resource pools and counters in web front-end development, the duplicate error prompt problem caused by the same error in concurrent network requests is solved, achieving more efficient error handling and better user experience.
Patent Information
- Application Number
- CN202510012443.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-06
- Publication Date
- 2025-04-29
AI Technical Summary
In modern web front-end development, when multiple concurrent network requests fail for the same reason, the traditional error handling mechanism will cause multiple duplicate error prompts to be displayed on the user interface, affecting the user experience and application performance.
Track and manage error messages by creating an error message resource pool and counter. The specific steps include initializing the error information resource pool and counter, updating the counter at the request initiation and ending, determining whether an error is displayed based on the resource pool, and processing the error prompt after all requests are completed.
It effectively reduces repeated error prompts on the interface, improves the systematicity and controllability of error handling, improves user experience and application performance, and simplifies error monitoring and analysis.
Smart Images
Figure CN119902953A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of computer network and Web development, and in particular to a method and system for processing identical errors in concurrent requests of a Web front-end network. Background Art
[0002] In modern web front-end development, applications often need to interact with the server through multiple network requests to implement functions such as dynamic content loading, form submission, data update, etc. With the popularity of single-page applications (SPA) and complex user interfaces, the number of network requests initiated simultaneously has increased. These requests may fail for a variety of reasons, such as network problems, server errors, session expiration, or insufficient permissions. When multiple concurrent requests fail for the same reason, traditional error handling mechanisms will cause multiple repeated error prompts to be displayed on the user interface, affecting user experience and application performance.
[0003] Existing implementation solutions on the market: In popular front-end frameworks such as Vue.js, React, Angular, and jQuery, the following methods are usually used to handle errors:
[0004] 1. Handle errors for each request individually:
[0005] This is the most direct method, and the error handling logic is included in the callback function of each network request. This method is simple and intuitive, but it cannot prevent repeated error prompts caused by concurrent requests.
[0006] 2. Global error handler:
[0007] Some frameworks provide global error handling capabilities, allowing developers to handle all uncaught exceptions in a centralized location. For example, Vue.config.errorHandler can be used in Vue, and Error Boundaries can be used in React. However, these mechanisms are usually used to capture errors in component rendering and lifecycle functions, rather than specifically for managing network request errors.
[0008] 3. State Management Library:
[0009] Using state management libraries such as Redux or Vuex can help developers better track application status, including error status. By storing error information in a global state tree, you can avoid repeatedly displaying the same error in the UI. However, this still requires developers to manually manage error status and design the state tree appropriately to avoid redundancy.
[0010] 4. Request interception and deduplication:
[0011] Before initiating a request, an interceptor is used to check whether there is an existing request in progress. If so, the request is blocked or merged to avoid repeated processing of the same error. This method relies on a sophisticated request management strategy and is relatively complex to implement.
[0012] Although the above methods have their own advantages, they still fail to effectively solve the problem of repeated error prompts caused by concurrent requests. Therefore, there is an urgent need for a method and system for handling the same errors in concurrent requests of a Web front-end network to solve the above technical problems. Summary of the invention
[0013] The purpose of the present invention is to provide a method and system for handling the same error of concurrent requests in a Web front-end network, so as to solve the problems raised in the above-mentioned background technology.
[0014] To achieve the above object, the present invention provides the following technical solutions:
[0015] A method for handling the same error of concurrent web front-end network requests, by creating an error information resource pool and a counter to track and manage errors, the method comprising the following steps:
[0016] Step 1: Initialize the error information resource pool and counters: Create an error information resource pool and related counters for the entire application or a specific module;
[0017] Step 2: Modify the counter when a request is initiated or ended: Whenever a request is initiated or ended, update the value of the counter;
[0018] Step 3: Determine whether to display an error based on the resource pool: For each error, first check whether it already exists in the error information resource pool. If not, add it to the resource pool and display the error prompt; if it already exists, ignore it to avoid repeated display;
[0019] Step 4: Processing after all requests are completed: After all requests are completed, decide whether to display an error prompt based on the records in the resource pool.
[0020] Preferably, a counter is used to track the number of currently active network requests, increasing the counter value when each network request is initiated and decreasing the counter value when the request is completed.
[0021] Preferably, the error information resource pool is used to store unique error information detected in multiple concurrent requests to prevent the same error from being prompted to the user multiple times. When a network request fails, the system checks whether the error information is already in the resource pool. If not, the error information is added to the resource pool and an error prompt is displayed to the user. If it already exists, the error is ignored and not displayed repeatedly.
[0022] Preferably, error prompt display and management are used to manage the display logic of error information to ensure that the user only sees each type of error once. When the request ends and the counter returns to zero, check whether there is an error record in the resource pool. If so, display the error prompt based on the record and clear the resource pool after the error is confirmed by the user.
[0023] Preferably, the detailed workflow of the method for handling the same error of concurrent requests of the Web front-end network includes the following stages:
[0024] S1, initialization phase: when the application starts, the initialization counter is set to 0; at the same time, an empty error information resource pool is established;
[0025] S2, request initiation and termination phase: Whenever a new network request is initiated, the counter increases by 1; whenever the request is successful or failed, the counter decreases by 1.
[0026] S3, error handling stage: If the request fails, compare the error information with the existing errors in the resource pool; if the error information does not exist in the resource pool, add it to the resource pool and display an error prompt to the user; if the error already exists in the resource pool, ignore it and do not display an error prompt.
[0027] S4. Processing after all requests are completed: After each request is completed, check whether the counter is 0 to determine whether all requests have been processed. If the counter is 0, further check the resource pool. If there are error records in the resource pool, process these errors uniformly and then clear the resource pool.
[0028] A system for processing identical errors in concurrent Web front-end network requests is applied in a method for processing identical errors in concurrent Web front-end network requests.
[0029] Compared with the prior art, the present invention has the following beneficial effects:
[0030] 1. Centralized management of error messages
[0031] The present invention effectively manages the error information generated by concurrent requests by creating an error information resource pool. This not only reduces repeated error prompts on the interface, but also makes error handling more systematic and controllable, greatly improving efficiency and maintainability compared to the decentralized processing of each request commonly adopted in the prior art.
[0032] 2. Improve user experience
[0033] By preventing multiple identical error messages from popping up at the same time, the user experience is significantly improved. Users no longer need to repeatedly close the same error prompt window, which reduces user fatigue and possible confusion, making the user interface cleaner and more user-friendly.
[0034] 3. Reduce resource consumption
[0035] In traditional methods, each error triggers an independent prompt process, including DOM operations and possible script execution, which may cause significant resource burden in applications with frequent concurrent requests. The present invention significantly reduces the computing and rendering burden of the client and improves the overall performance of the application by intelligently merging the same error prompts.
[0036] 4. Improved error monitoring and analysis
[0037] Since all errors are uniformly captured and recorded in the error information resource pool, it facilitates subsequent error monitoring and analysis. The development team can more easily track the patterns and frequency of errors, thereby more effectively locating the root causes of problems and making quality improvements.
[0038] 5. Flexible error handling strategies
[0039] The present invention allows developers to adjust the error handling logic according to actual application requirements, such as modifying the conditions for error display, customizing the display method of error information, etc. This flexibility is often difficult to achieve in the prior art, especially when using some closed frameworks. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:
[0041] Figure 1 The present invention is a flowchart of a method for handling the same error in concurrent requests of a Web front-end network. DETAILED DESCRIPTION
[0042] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the invention are shown in the accompanying drawings. The different types of section lines in the drawings in the embodiments of the present invention are not marked according to the national standard, nor are there any requirements for the materials of the components, but are used to distinguish the cross-sectional views of the components in the drawings.
[0043] See also Figure 1, a method for handling the same error of concurrent web front-end network requests, by creating an error information resource pool and a counter to track and manage errors, the method comprising the following steps:
[0044] Step 1: Initialize the error information resource pool and counters: Create an error information resource pool and related counters for the entire application or a specific module;
[0045] Step 2: Modify the counter when a request is initiated or ended: Whenever a request is initiated or ended, update the value of the counter;
[0046] Step 3: Determine whether to display an error based on the resource pool: For each error, first check whether it already exists in the error information resource pool. If not, add it to the resource pool and display the error prompt; if it already exists, ignore it to avoid repeated display;
[0047] Step 4: Processing after all requests are completed: After all requests are completed, decide whether to display an error prompt based on the records in the resource pool.
[0048] Among them, the counter is used to track the number of currently active network requests, increase the counter value when each network request is initiated, and decrease the counter value when the request is completed.
[0049] Among them, the error information resource pool is used to store unique error information detected in multiple concurrent requests to prevent the same error from being prompted to the user multiple times. When a network request fails, the system will check whether the error information is already in the resource pool. If not, the error information will be added to the resource pool and the error prompt will be displayed to the user; if it already exists, the error will be ignored and will not be displayed repeatedly.
[0050] Among them, error prompt display and management are used to manage the display logic of error information to ensure that users only see each type of error once. When the request ends and the counter returns to zero, check whether there is an error record in the resource pool. If so, display the error prompt according to the record and clear the resource pool after the error is confirmed by the user.
[0051] The detailed workflow of the method for handling the same error in concurrent web front-end network requests includes the following stages:
[0052] S1, initialization phase: when the application starts, the initialization counter is set to 0; at the same time, an empty error information resource pool is established;
[0053] S2, request initiation and termination phase: Whenever a new network request is initiated, the counter increases by 1; whenever the request is successful or failed, the counter decreases by 1.
[0054] S3, error handling stage: If the request fails, compare the error information with the existing errors in the resource pool; if the error information does not exist in the resource pool, add it to the resource pool and display an error prompt to the user; if the error already exists in the resource pool, ignore it and do not display an error prompt.
[0055] S4. Processing after all requests are completed: After each request is completed, check whether the counter is 0 to determine whether all requests have been processed. If the counter is 0, further check the resource pool. If there are error records in the resource pool, process these errors uniformly and then clear the resource pool.
[0056] A system for processing identical errors in concurrent Web front-end network requests is applied in a method for processing identical errors in concurrent Web front-end network requests.
[0057] It should be noted that, in view of the shortcomings of the prior art, the present invention provides a method and device for optimizing the Web front-end processing of concurrent network request errors, especially for the effective management of repeated errors such as session expiration and insufficient permissions. By introducing a counter and an error information resource pool mechanism, the present invention can reduce the number of repeated error prompts displayed on the user interface, thereby improving the user experience and improving application performance.
[0058] A new approach was taken to track and manage errors by creating an error information resource pool and counters. The specific steps include the following:
[0059] 1. Initialize the error information resource pool and counters: Create an error information resource pool and related counters for the entire application or a specific module;
[0060] 2. Modify the counter when a request is initiated and ended: Whenever a request is initiated or ended, update the value of the counter;
[0061] 3. Determine whether to display errors based on the resource pool: For each error, first check whether it already exists in the error information resource pool. If it does not exist, add it to the resource pool and display the error prompt; if it already exists, ignore it to avoid repeated display;
[0062] 4. Processing after all requests are completed: After all requests are completed, decide whether to display an error prompt based on the records in the resource pool.
[0063] The technical components of the present invention include the following aspects:
[0064] 1. Counter: Tracks the number of currently active network requests.
[0065] The counter is incremented when each network request is made and decremented when the request is completed. This ensures that the system knows how many network requests are in progress at any given moment.
[0066] 2. Error Information Resource Pool (Error Pool): Stores unique error information detected in multiple concurrent requests to prevent the same error from being prompted to the user multiple times.
[0067] When a network request fails, the system checks whether the error message is already in the resource pool. If not, the error message is added to the resource pool and an error message is displayed to the user; if it already exists, the error is ignored and not displayed again.
[0068] 3. Error prompt display and management: Manage the display logic of error information to ensure that users only see each type of error once.
[0069] When the request ends and the counter returns to zero, check whether there is an error record in the resource pool. If there is, display an error prompt based on the record, and clear the resource pool after the error is confirmed by the user.
[0070] The detailed workflow of the present invention includes the following stages:
[0071] 1. Initialization phase:
[0072] 1.1 When the application starts, the initialization counter is set to 0;
[0073] 1.2 At the same time, establish an empty error information resource pool.
[0074] 2. Request initiation and end stage:
[0075] 2.1 Every time a new network request is initiated, the counter increases by 1;
[0076] 2.2 When the request ends (whether successful or failed), the counter is reduced by 1.
[0077] 3. Error handling stage:
[0078] 3.1 If the request fails, compare the error information with the existing errors in the resource pool;
[0079] 3.2 If the error message does not exist in the resource pool, add it to the resource pool and display the error message to the user;
[0080] 3.3 If the error already exists in the resource pool, it will be ignored without any error prompt.
[0081] 4. Processing after all requests are completed:
[0082] 4.1 After each request, check whether the counter is 0 to determine whether all requests have been processed.
[0083] 4.2 If the counter is 0, further check the resource pool.
[0084] 4.3 If there are error records in the resource pool, handle these errors uniformly and then clear the resource pool.
[0085] The contents not described in detail in this specification belong to the prior art known to professionals in this field.
[0086] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the above features are replaced with (but not limited to) technical features with similar functions disclosed in the present application.
Claims
1. A method for handling the same error in concurrent web front-end network requests, which tracks and manages errors by creating an error information resource pool and a counter, and is characterized by: The processing method comprises the following steps: Step 1: Initialize the error information resource pool and counters: Create an error information resource pool and related counters for the entire application or a specific module; Step 2: Modify the counter when a request is initiated or ended: Whenever a request is initiated or ended, update the value of the counter; Step 3: Determine whether to display an error based on the resource pool: For each error, first check whether it already exists in the error information resource pool. If not, add it to the resource pool and display the error prompt; if it already exists, ignore it to avoid repeated display; Step 4: Processing after all requests are completed: After all requests are completed, decide whether to display an error prompt based on the records in the resource pool.
2. A method for handling the same error in concurrent requests of a Web front-end network according to claim 1, characterized in that: The counter is used to track the number of currently active network requests, increasing the counter value when each network request is initiated and decreasing the counter value when the request is completed.
3. A method for handling the same error in concurrent requests of a Web front-end network according to claim 1, characterized in that: The error information resource pool is used to store unique error information detected in multiple concurrent requests to prevent the same error from being prompted to the user multiple times. When a network request fails, the system checks whether the error information is already in the resource pool. If not, the error information is added to the resource pool and the error prompt is displayed to the user. If it already exists, ignore this error and do not display it again.
4. A method for handling the same error in concurrent requests of a Web front-end network according to claim 1, characterized in that: Error prompt display and management is used to manage the display logic of error information to ensure that users only see each type of error once. When the request ends and the counter returns to zero, check whether there is an error record in the resource pool. If so, display the error prompt based on the record and clear the resource pool after the error is confirmed by the user.
5. A method for handling the same error in concurrent requests of a Web front-end network according to claim 1, characterized in that: The detailed workflow of the method for handling the same error in concurrent web front-end network requests includes the following stages: S1, initialization phase: when the application starts, the initialization counter is set to 0; at the same time, an empty error information resource pool is established; S2, request initiation and termination phase: Whenever a new network request is initiated, the counter increases by 1; whenever the request is successful or failed, the counter decreases by 1. S3, error handling stage: if the request fails, compare the error information with the existing errors in the resource pool; if the error information does not exist in the resource pool, add it to the resource pool and display the error prompt to the user; If the error already exists in the resource pool, it is ignored without an error prompt. S4. Processing after all requests are completed: After each request is completed, check whether the counter is 0 to determine whether all requests have been processed. If the counter is 0, further check the resource pool. If there are error records in the resource pool, process these errors uniformly and then clear the resource pool.
6. A system for handling the same error in concurrent requests of a Web front-end network, characterized in that: The system for handling the same errors in concurrent requests of a Web front-end network is applied in the method for handling the same errors in concurrent requests of a Web front-end network described in claims 1-5.