Capturez et signalez les erreurs JavaScript avec Window.onerror

Points de base

• window.onerror est un événement de navigateur qui est déclenché lorsqu'une erreur JavaScript non apportée est lancée, fournissant un moyen facile de journaliser les erreurs du client et de les signaler au serveur. Tous les navigateurs modernes prennent en charge cet événement, mais les détails de mise en œuvre varient.
L'objet d'erreur transmis à
• est très précieux pour le débogage car il contient une trace de pile d'erreur qui fournit l'emplacement source pour chaque trame lorsque le programme erre. Cependant, l'attribut de pile est non standard et son implémentation est différente dans différents navigateurs. window.onerror
Bien que
• soit largement pris en charge, tous les navigateurs passent les objets d'erreur, ce qui signifie qu'ils ne peuvent pas récupérer les propriétés de trace de pile. Cette limitation peut être résolue en emballage le code dans un bloc Try / Catch pour attraper l'erreur et ses propriétés de pile. window.onerror
Après avoir attrapé l'erreur, la dernière étape consiste à transférer le message d'erreur vers le serveur. Cela nécessite la configuration d'un service Web de rapport qui recevra des données d'erreur sur HTTP, le connectez-le à un fichier et / ou les stockera dans une base de données. Si le service est situé dans un domaine différent, le partage de ressources inter-domaines (COR) doit être pris en charge.

Cet article est créé en collaboration avec Sentry. Merci de soutenir les partenaires qui ont rendu le point de point possible.

est un événement de navigateur spécial qui est déclenché chaque fois qu'une erreur JavaScript non apportée est lancée. C'est l'un des moyens les plus simples de connecter les erreurs du client et de les signaler au serveur. Il s'agit également de l'un des principaux mécanismes de l'intégration JavaScript du client de Sentry (Raven-JS) à fonctionner. window.onerror

Écoutez les événements

en attribuant des fonctions à window.onerror onerror

Lorsqu'une erreur est lancée, les paramètres suivants sont transmis à la fonction:

window.onerror = function (msg, url, lineNo, columnNo, error) {
  // ... 处理错误 ...

  return false;
}

- Message associé à une erreur, telle que "Uncing ReferenceError: FOO n'est pas défini"
• msg
- URL du script ou document associé à l'erreur, telle que "/dist/app.js"
• url
- Numéro de ligne (si disponible)
• lineNo
- Numéro de colonne (si disponible)
• columnNo
- Objet d'erreur associé à cette erreur (si disponible)
• error
Les quatre premiers paramètres vous indiquent quel script, ligne et colonne, l'erreur se produit. Le dernier paramètre, l'objet d'erreur, est peut-être le plus précieux. Comprenons pourquoi.

Objet d'erreur et erreur.stack

À première vue, l'objet d'erreur n'est pas spécial. Il contient 3 propriétés normalisées: message, nom de fichier et nombre de linais. Ces valeurs redondantes vous ont été fournies via

.

La partie précieuse est un attribut

non standard : . Cette propriété de pile vous indique l'emplacement source de chaque trame de programme lorsqu'une erreur se produit. Les traces de pile d'erreur peuvent être un élément clé du débogage. Bien que non standard, cette propriété est disponible dans chaque navigateur moderne. Error.prototype.stack

Ce qui suit est un exemple d'attributs de pile pour l'objet d'erreur dans Chrome 46:

window.onerror = function (msg, url, lineNo, columnNo, error) {
  // ... 处理错误 ...

  return false;
}

C'est difficile à lire, non? La propriété Stack n'est vraiment qu'une chaîne non formatée.

Ce qui suit est à quoi il ressemble après la mise en forme:

<code>"Error: foobar\n    at new bar (<anonymous>:241:11)\n    at foo (<anonymous>:245:5)\n    at <anonymous>:250:5\n    at <anonymous>:251:3\n    at <anonymous>:267:4\n    at callFunction (<anonymous>:229:33)\n    at <anonymous>:239:23\n    at <anonymous>:240:3\n    at Object.InjectedScript._evaluateOn (<anonymous>:875:140)\n    at Object.InjectedScript._evaluateAndWrap (<anonymous>:808:34)"
</anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></code>

Après la mise en forme, il est facile de voir comment la propriété Stack est cruciale pour aider à déboguer les erreurs.

Il n'y a qu'un seul problème: l'attribut de pile n'est pas standard, et son implémentation dans différents navigateurs est également différente. Par exemple, ce qui suit est la même trace de pile dans Internet Explorer 11:

<code>Error: foobar
    at new bar (<anonymous>:241:11)
    at foo (<anonymous>:245:5)
    at callFunction (<anonymous>:229:33)
    at Object.InjectedScript._evaluateOn (<anonymous>:875:140)
    at Object.InjectedScript._evaluateAndWrap (<anonymous>:808:34)
</anonymous></anonymous></anonymous></anonymous></anonymous></code>

Le format de chaque trame est non seulement différent, mais a également moins de détails. Par exemple, Chrome reconnaît que le nouveau mot-clé a été utilisé et a une compréhension plus approfondie des appels d'évaluation. Ce n'est qu'une comparaison entre IE 11 et Chrome - d'autres navigateurs ont également des formats et des détails différents.

Heureusement, il existe des outils qui peuvent normaliser les attributs de pile afin qu'ils soient cohérents entre les navigateurs. Par exemple, Raven-JS utilise Tracekit pour normaliser les chaînes d'erreur. Il y a StackTrace.js et quelques autres projets.

Compatibilité du navigateur

est là dans le navigateur depuis un certain temps - vous pouvez le trouver dans des navigateurs plus anciens comme IE6 et Firefox 2. window.onerror

Le problème est que chaque navigateur implémente

d'une manière différente, en particulier en termes de nombre de paramètres envoyés à l'écouteur ONERROR et de la structure de ces paramètres. window.onerror

Ce qui suit est un tableau des paramètres transmis à ONERROR dans la plupart des navigateurs:

Le support limité pour onerror dans Internet Explorer 8, 9 et 10 peut ne pas être surprenant. Mais vous pourriez être surpris de constater que Safari n'a pas ajouté de prise en charge des objets d'erreur avant Safari 10 (publié en 2016). De plus, les appareils mobiles hérités qui utilisent toujours le navigateur Android d'origine (désormais remplacé par Chrome Mobile) existent toujours et aucun objet d'erreur n'est passé.

S'il n'y a pas d'objet d'erreur, il n'y a pas de propriété de trace de pile. Cela signifie que ces navigateurs ne peuvent pas récupérer des informations précieuses de pile à partir d'erreurs capturées par onerror.

Utilisez Try / Catch pour fournir des polyfills pour Window.onerror

Mais il y a une solution de contournement - vous pouvez envelopper le code dans l'application dans un bloc d'essai / capture et attraper les erreurs vous-même. Cet objet d'erreur contiendra l'attribut de pile dont nous rêvons dans chaque navigateur moderne.

Considérez la méthode d'assistance suivante invoke, qui appelle une fonction sur un objet en utilisant une série de paramètres:

window.onerror = function (msg, url, lineNo, columnNo, error) {
  // ... 处理错误 ...

  return false;
}

Ce qui suit est appelé à nouveau invoke, cette fois enveloppé dans Try / Catch pour attraper toutes les erreurs lancées:

<code>"Error: foobar\n    at new bar (<anonymous>:241:11)\n    at foo (<anonymous>:245:5)\n    at <anonymous>:250:5\n    at <anonymous>:251:3\n    at <anonymous>:267:4\n    at callFunction (<anonymous>:229:33)\n    at <anonymous>:239:23\n    at <anonymous>:240:3\n    at Object.InjectedScript._evaluateOn (<anonymous>:875:140)\n    at Object.InjectedScript._evaluateAndWrap (<anonymous>:808:34)"
</anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></anonymous></code>

Bien sûr, il est très lourd de le faire manuellement n'importe où. Vous pouvez le simplifier en créant une fonction d'utilité de wrapper commune:

<code>Error: foobar
    at new bar (<anonymous>:241:11)
    at foo (<anonymous>:245:5)
    at callFunction (<anonymous>:229:33)
    at Object.InjectedScript._evaluateOn (<anonymous>:875:140)
    at Object.InjectedScript._evaluateAndWrap (<anonymous>:808:34)
</anonymous></anonymous></anonymous></anonymous></anonymous></code>

Parce que JavaScript est unique, vous n'avez pas besoin d'utiliser des wrappers partout - commencez simplement par chaque nouvelle pile.

Cela signifie que vous devez envelopper la déclaration de fonction:

• au début de l'application (par exemple, si vous utilisez jQuery, dans $(document).ready)
• dans le gestionnaire d'événements (par exemple, addEventListener ou $.fn.click)
• Callbacks basés sur le minuteur (par exemple setTimeout ou requestAnimationFrame)

Exemple:

<code>Error: foobar
   at bar (Unknown script code:2:5)
   at foo (Unknown script code:6:5)
   at Anonymous function (Unknown script code:11:5)
   at Anonymous function (Unknown script code:10:2)
   at Anonymous function (Unknown script code:1:73)</code>

Si cela ressemble à beaucoup de travail, ne vous inquiétez pas! La plupart des bibliothèques de reporting de bogues ont des mécanismes qui améliorent les fonctions intégrées telles que addEventListener et setTimeout, vous n'avez donc pas à appeler vous-même à chaque fois l'utilitaire de wrapper. Oui, Raven-Js fait de même.

Transférer les erreurs vers le serveur

ok, vous avez fait votre travail - vous avez inséré window.onerror, et vous avez également enveloppé la fonction dans un bloc d'essai / capture pour capturer autant d'informations d'erreur que possible.

Une seule dernière étape est laissée: transférer le message d'erreur vers le serveur. Pour que cela fonctionne, vous devez configurer une sorte de service Web de rapport qui recevra vos données d'erreur via HTTP, la connectez-la à un fichier et / ou les stockera dans une base de données.

Si ce service Web se trouve sur le même domaine que votre application Web, utilisez simplement XMLHTTPREQUEST. Dans l'exemple suivant, nous utilisons la fonction AJAX de JQuery pour transférer des données vers notre serveur:

function invoke(obj, method, args) {
    return obj[method].apply(this, args);
}

invoke(Math, 'max', [1, 2]); // 返回 2

Notez que si vous devez transmettre des erreurs entre différentes sources, votre point de terminaison de rapport doit prendre en charge le partage de ressources inter-domaines (COR).

Résumé

Si vous l'avez fait, vous avez maintenant tous les outils nécessaires pour faire défiler votre propre bibliothèque de reporting d'erreur de base et l'intégrer à votre application:

Comment
• window.onerror fonctionne et ses navigateurs pris en charge
• Comment utiliser Try / Catch pour capturer window.onerror Trace de pile manquante
• Transférer des données erronées sur le serveur

Bien sûr, si vous ne voulez pas vous soucier de tout cela, il existe de nombreux outils commerciaux et open source qui peuvent faire tout le monde de la rapports de clients pour vous. (Shh: vous voudrez peut-être essayer d'utiliser Sentry pour déboguer JavaScript.)

c'est tout! Surveillance des erreurs heureuse.

FAQ (FAQ) sur l'utilisation de Window.onerror pour capturer et signaler les erreurs JavaScript

window.onerror Comment fonctionnent les fonctions en JavaScript?

L'événement window.onerror dans JavaScript est un gestionnaire d'événements global qui est déclenché lorsqu'une erreur se produit lors de l'exécution du code JavaScript. Il s'agit d'un puissant outil de débogage et de gestion des erreurs car il peut attraper et signaler des exceptions non apprises ou des erreurs d'exécution. Lorsqu'une erreur se produit, la fonction window.onerror sera appelée avec cinq paramètres: message d'erreur, URL où l'erreur s'est produite, le numéro de ligne, le numéro de colonne et l'objet d'erreur.

Quelle est la différence entre window.onerror et le coup d'essai en javascript?

window.onerror et les coups d'essai sont tous deux utilisés pour la gestion des erreurs en JavaScript, mais ils fonctionnent différemment. L'instruction TRYPRACCH vous permet de gérer directement l'erreur en enveloppe le code qui peut lancer une erreur dans un bloc d'essai, puis en répondant à l'erreur dans le bloc de capture. D'un autre côté, window.onerror est un gestionnaire d'événements mondial qui est déclenché lorsqu'une erreur d'exécution non apportée se produit. Il s'agit d'un mécanisme de gestion des erreurs plus général qui capture des erreurs qui glissent du bloc d'essai.

Comment utiliser window.onerror pour assister aux erreurs JavaScript?

Pour utiliser window.onerror, vous devez définir une fonction qui sera appelée lorsqu'une erreur se produit. Cette fonction doit prendre cinq paramètres: message d'erreur, URL où l'erreur s'est produite, le numéro de ligne, le numéro de colonne et l'objet d'erreur. À l'intérieur de cette fonction, vous pouvez gérer les erreurs au besoin. Par exemple, vous pouvez enregistrer des erreurs à la console, envoyer des rapports au serveur ou afficher des messages aux utilisateurs.

window.onerror Tous les types d'erreurs JavaScript peuvent-ils être capturés?

Bien que window.onerror soit un puissant outil de gestion des erreurs, il a certaines limites. Il peut attraper les erreurs d'exécution les plus non apprises, mais il ne peut pas prendre des exceptions lancées et prises dans le bloc de coups d'essai. De plus, certains types d'erreurs, tels que les erreurs de réseau ou les erreurs COR, peuvent ne pas déclencher l'événement window.onerror.

Comment utiliser un objet d'erreur dans window.onerror?

L'objet d'erreur

est le cinquième paramètre transmis à la fonction window.onerror. Il contient des informations sur une erreur s'est produite, y compris les messages d'erreur, les noms d'erreur et les traces de pile. Vous pouvez utiliser cet objet pour obtenir des informations plus détaillées sur l'erreur, ce qui est très utile pour le débogage ou les rapports d'erreur.

Quelle est la trace de pile en javascript?

La trace de pile est un rapport qui fournit des informations sur le chemin d'exécution du programme lorsqu'une erreur se produit. Il affiche la séquence des appels de fonction qui provoquent l'erreur, ce qui est très utile pour le débogage. Dans JavaScript, vous pouvez obtenir une trace de pile à partir d'un objet d'erreur.

Comment obtenir la trace de pile en javascript?

Dans JavaScript, vous pouvez obtenir une trace de pile à partir d'un objet d'erreur. Lorsqu'une erreur se produit, un objet d'erreur est créé et transmis à la fonction window.onerror. Cet objet a une propriété appelée pile qui contient la trace de pile. Vous pouvez accéder à cette propriété pour obtenir une trace de pile.

Puis-je utiliser window.onerror pour signaler l'erreur au serveur?

Oui, vous pouvez utiliser window.onerror pour signaler les erreurs au serveur. À l'intérieur de votre fonction window.onerror, vous pouvez envoyer une demande au serveur avec un message d'erreur. Ceci est très utile pour surveiller et déboguer, car il vous permet de collecter et d'analyser les données d'erreur des utilisateurs en temps réel.

Comment utiliser window.onerror pour gérer les erreurs CORS?

Erreur CORS ou L'erreur de partage des ressources inter-domaines se produit lorsqu'une application Web essaie d'accéder aux ressources à partir d'un domaine différent. Ces erreurs sont liées à la sécurité et pour des raisons de sécurité, aucun détail n'est fourni au gestionnaire d'événements window.onerror. Cependant, vous pouvez gérer ces erreurs en ajoutant un gestionnaire d'erreurs à une demande de réseau spécifique qui peut entraîner des erreurs CORS.

Quelles sont les meilleures pratiques pour utiliser window.onerror?

Lorsque vous utilisez window.onerror, assurez-vous de gérer les erreurs d'une manière qui n'interrompt pas l'expérience utilisateur. Vous devez éviter d'afficher des messages d'erreur techniques aux utilisateurs. Pensez plutôt à afficher un message d'erreur amical ou à enregistrer silencieusement une erreur. Soyez également conscient de l'impact des performances du code de gestion des erreurs. Par exemple, si vous envoyez un rapport d'erreur au serveur, assurez-vous de le faire de manière asynchrone afin qu'il ne bloque pas le thread principal.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!