In H5 development, error handling and monitoring can improve robustness through four major means: global error monitoring, interface request exception interception, user behavior burial, and log aggregation alarm. 1. Use window.onerror and window.onunhandledrejection to capture global errors and report them; 2. Use Axios/Fetch interceptor to handle interface exceptions, distinguish 4xx/5xx errors and implement retry strategies; 3. Record user key operation assisted scenes, and regularly report behavior logs; 4. Connect to Sentry and other platforms to realize log aggregation and alarms, combine session ID tracking problems, and optimize duplicate error filtering and offline cache strategies.

In H5 development, error handling and monitoring are not the kind of "visible" features, but they determine the bottom line of the user experience. Especially on mobile terminals, the network environment is complex and the equipment is seriously fragmented. If you are not careful, you may cause page crash or user churn. Therefore, a robust H5 application must have a complete error capture mechanism and real-time exception monitoring capabilities.

Let’s start from several actual scenarios and talk about how to do this well.

Global error monitoring: Don't let the exception "slide away quietly"

The browser provides some native global error listening interfaces, such as window.onerror and window.onunhandledrejection , which are the basic but very critical lines of defense.

• window.onerror can capture syntax errors, runtime errors, etc. in script execution.
• window.onunhandledrejection is used to listen for unprocessed Promise rejection to prevent asynchronous errors from being ignored.

 window.onerror = function(message, source, lineno, colno, error) {
  console.error('Global error catch:', message, error);
  // Report to the server return true; // Block default processing};

?? Note:

• Don't rely on the message field for precise judgment, it may vary from browser to browser.
• Source map must be uploaded with the backend, otherwise the reported error stack is compressed code, which is difficult to locate the problem.

Unified interception of interface request exceptions: Don't let failure "no trace"

The H5 page cannot be separated from communication with the server. Any failure of the interface call may be a cause of user lag or even exit. Therefore, it is recommended to uniformly intercept all requests, record failure information and try to recover or prompt.

If you are using Axios or Fetch:

Axios example:

 axios.interceptors.response.use(
  response => response,
  error => {
    const { config, response } = error;
    if (response) {
      // The request has been issued, but the server returns a non-2xx status code console.error(`API Error: ${config.url}`, response.status, response.data);
    } else if (error.request) {
      // The request is not responded (such as timeout)
      console.error(`No response for ${config.url}`);
    } else {
      // Other errors console.error('Unexpected request error', error.message);
    }
    return Promise.reject(error);
  }
);

? suggestion:

• For 4xx errors, they can be reported according to business logic, such as login failure, parameter errors, etc.
• For 5xx errors, you can consider the automatic retry mechanism to improve fault tolerance.

Auxiliary inspection of user behavior burial points: know what the user did at that time

Many times, you receive an error log but don't know what operation the user did at that time causing the problem. At this time, it is necessary to analyze it in combination with user behavior data.

It can simply record the user's key actions, such as clicking buttons, form submissions, page jumps and other events, and bringing a timestamp and the current page path.

 const userActions = [];

function trackAction(name) {
  const action = {
    name,
    time: new Date().toISOString(),
    path: window.location.pathname
  };
  userActions.push(action);
  // Clean or report regularly}

Recommended reporting method:

• Send several recent operations together when an error occurs to help restore the scene.
• There is no need to report every operation to avoid affecting performance.

Log aggregation and alarm mechanism: Don’t wait until the user complains before taking action

It is not enough to just catch errors, and someone must see these exceptions as soon as possible. Error logs can be collected uniformly on a certain platform, such as Sentry, LogRocket or self-built logging system.

Recommended practices:

• Set alarm rules according to error type, frequency, and impact surface (such as a certain type of error triggers more than 10 notifications per minute).
• Track the exception path of a specific user in combination with the user ID or session ID.
• Control the reporting frequency to avoid interference caused by screen-sweeping logs.

Some details are easy to ignore:

• Mobile terminals should consider the cache strategy in case of network disconnection, and then re-transmit the log after the network is restored.
• Repeated errors need to be filtered to avoid large-scale reports of the same error in a short period of time.

Basically that's it. Error monitoring is not a one-time transaction, it requires continuous optimization. Doing a better job will not only help you quickly locate problems, but also discover potential risks in advance, truly realizing "preventing problems before they happen."

The above is the detailed content of Advanced Error Handling and Monitoring in H5. For more information, please follow other related articles on the PHP Chinese website!