En Javascript, est-il coûteux à l'utilisation de blocs try-catch, même si une exception n'est jamais jeté?

Qu'il est "lent" pour utiliser plusieurs blocs try-catch quand, sans exception, sont jetés dans l'un d'eux? Ma question est la même que cette une, mais pour le Javascript.

Supposons que j'ai 20 fonctions qui ont les blocs try-catch en eux. Et une autre fonction qui appelle chacun de ces 20 fonctions. Aucun d'entre eux va lever une exception. Mon code s'exécuter plus lentement ou faire bien pire à cause de cela les blocs try-catch?

  • stackoverflow.com/questions/12609527/...
  • mais n'est-ce pas en parler, lorsque les exceptions sont pris?
  • Il y a beaucoup de bonnes Try/Catch tests de performance sur jsperf: jsperf.com/search?q=Try/Catch. Dans la plupart des cas, la try est assez négligeable, mais cela dépend un peu de votre définition de slow. Si vous êtes à la recherche de la performance, alors il ya beaucoup de meilleures options puis try/catch. @Roland fait un bon travail de la liste d'un peu plus de bonnes raisons de ne pas les utiliser ainsi.
  • Bien 99% de jsperfs sont brisées, et à d'autres moments, ils sont trompeurs et ne pas donner des infos utiles. Bien sûr, une fonction qui à peine n'importe quoi est seulement un peu moins lent avec un try catch.
  • Certainement pas valoir que, comme vous le savez probablement plus que moi =) Juste jeter mes 2 cents dans le cas de quelqu'un le trouve utile.
  • Ainsi, selon l'autre réponse, bref, la réponse à ma question, d'où je dois mettre en surbrillance lorsqu'une exception est jamais jeté, est NON, c'est pas cher si les exceptions ne sont pas jetés.
  • ici, un simple indice qui devrait vous aider: jsben.ch/#/fbhRD
  • developerknowhow.com/364/javascript-trycatch-performance-hit

InformationsquelleAutor cprcrack | 2013-11-01
  1. 52

    Faites-vous typique CRUD code de l'INTERFACE utilisateur? Essai d'utilisation des captures, utiliser les boucles qui vont 10000 pour aucune raison saupoudré dans votre code, l'enfer, l'utilisation angulaire/ember - vous ne verrez pas un problème de performance.

    Si vous faites le faible niveau de la bibliothèque, de la physique, de simulations, de jeux, côté serveur, etc alors la jamais jeter bloc try-catch normalement n'a pas d'importance du tout, mais le problème est que le V8 n'a pas de soutien dans leur compilateur optimisant jusqu'à la version 6 du moteur, de sorte que l'ensemble de la fonction contenante que du point de vue syntaxique contient un try catch ne sera pas optimisé. Vous pouvez facilement travailler autour de ce que, par la création d'une fonction d'assistance comme tryCatch:

    function tryCatch(fun) {
    try {
        return fun();
    }
    catch(e) {
        tryCatch.errorObj.e = e;
        return tryCatch.errorObj;
    }
}
tryCatch.errorObj = {e: null};


var result = tryCatch(someFunctionThatCouldThrow);
if(result === tryCatch.errorObj) {
    //The function threw
    var e = result.e;
}
else {
    //result is the returned value
}

    Après le V8 de la version 6 (livré avec le Nœud 8.3 et dernier Chrome), l'exécution de code à l'intérieur try-catch est la même que celle de la normale code.

    • Si c'est le cas avec les V8, ce serait vraiment faire une différence, et votre code ressemble à une bonne idée pour résoudre ce problème. Pourriez-vous fournir un lien avec la source de l'information qui stipule que le V8 ne pas optimiser les fonctions avec les blocs try-catch? Savez-vous si cela s'applique à d'autres compilateurs Javascript ou des interprètes?
    • Je ne sais pas pour vous, essayez de l'attraper est surtout nécessaire sur le côté serveur donc il ne devrait pas être une priorité pour optimiser. Voir ici pour le V8 de la source où l'optimisation du compilateur écope quand il voit try catch dans une fonction github.com/v8/v8/blob/master/src/hydrogen.cc#L3922-L3927
    • reportez-vous à jsperf.com/try-catch-performance-overhead
    • "Pas toutes les fonctions peuvent être optimisés, cependant certaines fonctionnalités de prévenir le compilateur d'optimisation de l'exécution sur une fonction donnée (un "bail-out"). En particulier, le compilateur optimisant actuellement écope sur les fonctions avec le try {} catch {} blocs!" Source: html5rocks
    • Par souci de garder la réponse jusqu'à ce jour, il convient de noter que le nouveau V8 à double flux compilateur soutien try-catch optimisation, même si c'est encore à quelques mois de la prise en Chrome et Nœud. Voir, par exemple, codereview.chromium.org/1996373002
    InformationsquelleAutor Esailija
  2. 38

    La question d'origine interrogé sur le coût de try/catch lorsqu'une erreur n'a pas été levée. Il y a certainement un impact lors de la protection d'un bloc de code avec try/catch, mais l'impact de try/catch va disparaître rapidement que le code protégé devient même un peu complexe.

    Pencher sur ce test: http://jsperf.com/try-catch-performance-jls/2

    Une simple incrémentation des pistes de 356,800,000 itérations par seconde
    Le même incrément dans un try/catch est 93,500,000 itérations par seconde. C'est sur les frais généraux de 75% en raison du try/catch.
    MAIS, un banal appel de fonction s'exécute à 112,200,000 itérations par seconde.
    2 trivial appels de fonction à exécuter à 61,300,000 itérations par seconde.

    Non-exercice de l'essayer dans ce test prend légèrement plus de temps que d'un banal appel de fonction. C'est à peine d'une pénalité sur la vitesse qui compte, sauf dans le plus intérieur de la boucle de quelque chose de vraiment intense comme une FFT.

    Le cas où vous souhaitez les éviter, c'est le cas où une exception est générée. C'est infiniment plus lent, comme indiqué dans le lien ci-dessus.

    Edit: Ces chiffres sont ceux de google Chrome sur mon ordinateur. Dans Firefox, il n'y a pas de différence significative entre les options en jeu non levées essayer et pas de protection du tout. Il y a essentiellement aucune pénalité à l'aide de try/catch si aucune exception n'est levée.

    InformationsquelleAutor asthomas
  3. 8

    La try-catch bloc est dit être cher. Toutefois, si les critiques de la performance n'est pas un problème, ne l'est pas nécessairement un sujet de préoccupation.

    La peine de l'OMI:

    • lisibilité
    • inapproprié dans de nombreux cas,
    • inefficace quand il s'agit de programmation asynchrone

    Lisibilité: la plomberie de votre code avec beaucoup de try-catch, c'est moche et distrayant

    inapproprié: c'est une mauvaise idée d'insérer un tel bloc si votre code n'est pas assujettie à l'exception de l'accident. Insérer uniquement si vous vous attendez à un échec dans votre code. Jetez un oeil à la rubrique suivante: Quand utiliser les blocs try/catch?

    Async: le try-catch bloc est synchrone et n'est pas efficace quand il s'agit de async de programmation. Au cours d'une ajax demande de vous traiter à la fois de la error et success événements dans les rappels. Pas besoin de try-catch.

    Espère que cette aide,

    R.

    • "Il est dit à l'est du ouï-dire. Veuillez fournir des preuves, ne pas encourager les programmeurs prématurément optimiser.
    • C'est la connerie. Il y a beaucoup de situations "exceptionnelles" qui ne sont pas un "échec". Les Exceptions sont un puissant outil de construction de programmation.
    • J'ai testé la performance de supposer que cette variable est appelable contre le tester en premier. Vérifier avec un si la déclaration a été ordres de grandeur plus rapide que la mendicité pour le pardon avec un try/catch: jsperf.com/try-catch-performance-jls
    • Concernant la pertinence async fonctions, en gros, c'est maintenant par défaut à utiliser try catch combiné avec ES7 async vous attendent. Vous souhaitez mettre à jour votre réponse pour refléter le fait que le développement récent.
    • Une autre importante pour un try/catch vs approche de gestion des erreurs avec des rappels asynchrones est qu'accidentellement jeter (par exemple, une faute de frappe ou difficiles à manquer erreur de logique) dans le code de gestion des erreurs à l'intérieur de votre rappel asynchrone sera probablement planter le processus, alors qu'accidentellement jeter (par exemple, une faute de frappe ou difficiles à manquer erreur de logique) dans un catch bloc ne sera pas. Il y a également d'importants avantages pour les try/catch avec await vs erreur de manipulation via promesse de chaînage, mais qui est hors de portée de ce commentaire. Plus sur: gist.github.com/mikermcneil/c1028d000cc0cc8bce995a2a82b29245
    InformationsquelleAutor roland