web-dev-qa-db-fra.com

Quelles sont les meilleures pratiques pour la gestion des erreurs JavaScript?

Je cherche à rendre mon code JavaScript un peu plus résistant aux erreurs et je trouve une documentation abondante sur l'utilisation de try, catch, finally et throw, mais je ne trouve pas une tonne de conseils d'experts sur quand et où jeter des erreurs.

  • Chaque morceau de code devrait-il être emballé dans un essai/attrape?
  • Y at-il plus de conseils comme this on à quel point les erreurs doivent être détectées?
  • Y a-t-il des inconvénients à générer des erreurs au lieu que le code échoue silencieusement en production?
  • Cela a été évoqué le SO en ce qui concerne les implémentations, mais les erreurs JS de journalisation de serveur sont-elles une stratégie efficace?
  • Que dois-je savoir d'autre concernant les erreurs de piégeage dans ma candidature?

Je suis aussi complètement prêt à entendre parler de livres qui contiennent d'excellents chapitres ou des explications détaillées sur la gestion des erreurs. JavaScript éloquent aborde le sujet, mais n’est pas très normatif ou ne suscite pas d’opinion.

Merci pour tout conseil que vous pouvez donner!

javascripterror-handling
128
Joshua Cody

Vous trouverez une série extrêmement intéressante de diapositives sur le traitement des erreurs JavaScript dans Enterprise à l'adresse suivante: http://www.devhands.com/2008/10/javascript-error-handling-and-general-best- pratiques/

En bref, il résume:

  1. Supposer que votre code va échouer
  2. Enregistrer les erreurs sur le serveur
  3. Vous, pas le navigateur, gérez les erreurs
  4. Identifier où des erreurs peuvent se produire
  5. Jetez vos propres erreurs
  6. Distinguer les erreurs fatales des erreurs non fatales
  7. Fournir un mode de débogage

Les diapositives vont beaucoup plus en détail et vous donneront probablement une direction.

MISE À JOUR

La présentation mentionnée ci-dessus peut être trouvée ici: http://www.slideshare.net/nzakas/enterprise-javascript-error-handling-presentation

58
cdmdotnet

Nicholas Zakas de Yahoo! La célébrité a fait un exposé sur le traitement des erreurs d'entreprise ( slides ) à Ajax Experience 2008, dans lequel il a proposé quelque chose comme ceci:

function log(sev,msg) {
    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

// usage
log(1, "Something bad happened.")

// Auto-log uncaught JS errors
window.onerror = function(msg, url, line) {
    log(1, msg);
    return true;
}

Un an plus tard, Nicholas Zakas publiait un mise à jour sur son blog , qui incluait un modèle astucieux pour injecter automatiquement du code de gestion des erreurs dans votre environnement de production (à l'aide d'une programmation orientée aspect).

Lorsque vous démarrez la journalisation des appels window.error, vous remarquerez deux choses:

  1. Si votre site est assez complexe, vous allez enregistrer un lot d'erreurs.
  2. Vous verrez un tas de messages "window.error in undefined: 0" inutiles.

Réduire le torrent des entrées de journal est aussi simple que de tester la gravité et/ou un nombre aléatoire avant de se connecter au serveur:

function log(sev,msg) {
    if (Math.random() > 0.1) return; // only log some errors

    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

La gestion des erreurs inutiles "window.error in undefined: 0" dépend de l'architecture de votre site, mais peut essayer d'identifier tous les appels Ajax et de lever une exception en cas d'échec (le renvoi éventuel d'une trace de pile à l'aide de stacktrace.js ).

30
Jens Roland

IHMO, vous devez utiliser la gestion des erreurs en javascript comme dans plusieurs autres langages (AFAIK: Python, Java).

Pour une meilleure lisibilité (et probablement de meilleures performances, même si je ne suis pas sûr que cela ait un impact très important), vous devez utiliser le bloc try/catch principalement dans les cas suivants:

  • La partie du code que vous voulez insérer est une clé partie de l'algorithme complet. Si cela échoue, il pourrait:

    • créer des erreurs sur la partie suivante des codes (par exemple, une variable manquante ...)
    • faire en sorte que la page ne corresponde pas aux attentes (impact sur le contenu ou les CSS)
    • rendre les résultats étranges pour l'utilisateur (impact sur le comportement du code)

  • Vous savez que le code que vous écrivez est non compatible avec tous les navigateurs

  • Vous avez prévu que le le code peut échouer (car il n'y a pas d'autre moyen de vérifier qu'il fonctionne correctement si ... alors ... bloque)
  • Et aussi quand vous voulez debug sans déranger l'utilisateur final

Finalement, les experts en javascript peuvent avoir d'autres éléments à fournir.

mes 2 cents à la boîte,

Cordialement,

Max

7
JMax

En plus des autres réponses: une chose importante est d'utiliser les données de contexte disponibles dans les objets d'erreur JavaScript et dans les paramètres de la fonction window.onerror.

Des choses comme le stacktrace (errorObject.stack), le nom du fichier, le numéro de ligne et le numéro de colonne. Notez que chaque navigateur a quelques différences ... alors faites de votre mieux pour obtenir les erreurs de Nice.

Il peut même y avoir des problèmes avec le objet console lui-même . J'utilise ne fonction window.onerror personnalisée inspirée de celle-ci et une fonction spéciale permettant de tracer un objet d'erreur standard donné inspiré de ce code .

Un autre avantage est d’inclure la version de votre application Web quelque part à proximité du chemin de pile (pour un copier-coller rapide et sûr). Vous pouvez également afficher des erreurs plus agressives (alerte ...) en mode de développement, car les développeurs ne surveilleront pas constamment la console du navigateur et risquent de ne pas voir certains des problèmes.

Évitez également d'utiliser throw 'My message', Utilisez throw new Error('My message'), vous pouvez même avoir des erreurs personnalisées, lisez cet article .

Ajoutez toujours un contexte aux erreurs (la version, l'id de l'objet, des messages personnalisés, ...) et veillez également à faire la distinction entre les erreurs externes (certaines données externes ou la force a fait échouer votre système) et les erreurs internes./assertions (votre propre système foiré), lisez sur ' Conception par contrat '.

Voici un guide .

Pensez également à utiliser le traitement général des erreurs comme des intercepteurs dans vos bibliothèques et vos frameworks:

4
Christophe Roussy