Javascript: Quel est plus efficace, bloc IF ou ESSAYER / CATCH?

Question

J'aimerais d'autres opinions sur ce qui est plus efficace dans ce code. En gros, dans le code suivant, il y a une boucle setInterval et je dois 4 exigences pour être vrai avant que le code fonctionne dans la boucle. Donc, en v.1 j'ai écrit une instruction if vérifiant tous les 4. ont fonctionné très bien.

Ensuite, je suis passé à utiliser simplement try / catch, avec le code que je veux exécuter assis dans try {}. La logique est que lors de chaque boucle, une exception sera générée mais supprimée pour chaque condition invalide. Sur la boucle finale où toutes les conditions sont remplies, le code exécute et efface l'intervalle.

Soit fonctionne. J'aime la méthode try / catch parce qu'il ya moins de code sous condition que je dois écrire et se soucier de violer. Mais je suis inquiet que try / catch est vraiment inefficace, en particulier dans une boucle setInterval () frapper à 100ms. Quels sont les opinions des autres esprits brillants ici sur le SO?

try / catch

var intvar = setInterval(function(){
try{    
    clearInterval(intvar);

    jQuery('#'+nav[pageid].t1+'>a').replaceWith(jQuery('<span>'+jQuery('#'+nav[pageid].t1+'>a').text()+'</span>'));

    //set display classes for nav
    jQuery('#'+nav[pageid].t1).addClass('selected').find('#'+nav[pageid].t2).addClass('subselect'); //topnav
    jQuery('#'+nav[pageid].t3).addClass('selected').find('#'+nav[pageid].t4).addClass('subselect'); //leftnav
}catch(err){}
},100);

Si le bloc

var intvar = setInterval(function(){

if(typeof jQuery == 'function' && typeof nav == 'object' && typeof pageid != 'undefined' && typeof document.getElementById('leftnav') == 'object'){
    clearInterval(intvar);
    jQuery('#'+nav[pageid].t1+'>a').replaceWith(jQuery('<span>'+jQuery('#'+nav[pageid].t1+'>a').text()+'</span>'));

    //set display classes for nav
    jQuery('#'+nav[pageid].t1).addClass('selected').find('#'+nav[pageid].t2).addClass('subselect'); //topnav
    jQuery('#'+nav[pageid].t3).addClass('selected').find('#'+nav[pageid].t4).addClass('subselect'); //leftnav
}

},100);

Answer 1

Utilisez l'instruction if. Je ne sais pas ce que les frais généraux est pour un essai / CATCH, mais je pense qu'il est beaucoup plus grande que l'évaluation d'une expression booléenne. Pour frapper la TRY / CATCH vous devrez: exécuter une instruction, générer une erreur [avec que les frais généraux associés], connectez-vous l'erreur (probablement), a fait une stacktrace (probablement), et est retourné dans le code. De plus, si vous avez le code de débogage à proximité de ces lignes l'erreur réelle pourrait s'obscurcie avec ce que vous TRY / Attraper.

En outre, il est un abus de TRY / CATCH et peut rendre votre code beaucoup plus difficile à lire. Supposons que vous faites cela pour les cas plus ou plus brouillées? Où pourrait finir votre rattraper?

est appelée Gestion des exceptions

EDIT:. Comme commenté ci-dessous, vous prenez seulement la performance d'exécution a frappé si vous causez en fait une exception

Answer 2

Les exceptions devraient être utilisées dans des circonstances exceptionnelles (à savoir des choses que vous ne vous attendez pas à passer normalement). Vous ne devriez pas, en général, les exceptions d'utilisation pour attraper quelque chose que vous pouvez tester avec une instruction if.

En outre, d'après ce que je comprends, les exceptions sont beaucoup plus chers que si les déclarations.

Answer 3

Les autres réponses sont correctes, try/catch est dans des circonstances exceptionnelles et la gestion des erreurs. conditions de if sont pour la logique du programme. "Lequel est plus vite?" est la mauvaise question.

Une bonne règle générale, si vous faites rien à l'exception, il est probablement pas une exception!

Pour savoir lequel utiliser, cassons votre si la condition.

1. typeof jQuery == 'function' est la fonction jQuery () définie?
2. typeof nav == 'object' Est-ce que la variable globale nav contient un objet?
3. typeof pageid != 'undefined' est la variable globale définie pageid?
4. typeof document.getElementById('leftnav') == 'object' Le document contient un élément leftnav?

Le premier est clairement une exception. Vous ne reçoit pas loin sans fonction jQuery ().

La seconde est également une exception. Vous ne va nulle part sans objet nav.

Le troisième est une exception. Vous avez besoin d'un pageid à faire quoi que ce soit.

Le quatrième est probablement logique. « Ne faites fonctionner ce code s'il y a un élément leftnav ». Il est difficile de dire parce que le reste du code ne fait pas référence à un élément leftnav! Seuls les commentaires font, un drapeau rouge. Il est donc probablement une erreur de programmation.

Je serais probablement le faire (avec mes excuses si je suis dépeçage jQuery):

var intvar = setInterval(function() {
    // If there's no leftnav element, don't do anything.
    if( typeof document.getElementById('leftnav') != 'object') {
        return;
    }

    try {
        clearInterval(intvar);
        jQuery('#'+nav[pageid].t1+'>a')
            .replaceWith(jQuery('<span>'+jQuery('#'+nav[pageid].t1+'>a').text()+'</span>'));

        //set display classes for nav
        jQuery('#'+nav[pageid].t1)
            .addClass('selected')
            .find('#'+nav[pageid].t2)
            .addClass('subselect');     //topnav
        jQuery('#'+nav[pageid].t3)
            .addClass('selected')
            .find('#'+nav[pageid].t4)
            .addClass('subselect');     //leftnav
    }
    catch(err) {
        ...do something with the error...
    }
},100);

... mais je voudrais vraiment examiner si le contrôle de l'élément leftnav est applicable.

Enfin, je ne peux que commenter que cette « fonction » travaille avec des variables globales. Vous devriez plutôt être de passage nav et pageid dans la fonction afin de maintenir l'encapsulation et votre santé mentale.

Answer 4

Je voudrais écrire le code suivant:

var startTime = (new Date()).getTime();
for (var i=0; i < 1000; ++i) intvar();
var endTime = (new Date()).getTime();
alert("Took " + ((endTime - startTime) / 1000.0) " seconds");

Alors je voudrais essayer les deux versions de IntVar et de voir ce qui fonctionne plus rapidement. Je le ferais moi-même mais je n'ai pas la mise en page que vous le faites mon code ne fonctionnerait pas.

Quelques commentaires stylistiques - il ne semble pas nécessaire de vérifier que jQuery est une fonction. Dans le cas contraire, votre page Web est probablement foiré de telle sorte que ne pas courir le code intvar ne vous aidera pas. Si vous prévoyez rarement les exceptions à jeter, j'utiliser le try / catch.

Answer 5

Pour l'exemple fourni où vous envelopper un try / catch autour d'un bloc de code qui doit toujours fonctionner de toute façon (sauf si quelque chose d'horrible arrive), il est bon d'utiliser les try / catch. Une analogie pour vous: testez-vous toujours « Est-ce le ciel bleu? » dans votre déclaration si, ou vous envelopper dans un try / catch qui se déclenche que lorsque le ciel se verdir.

Utilisez la méthode de déclaration Si si vous faites affaire avec entrée fourni utilisateur ou si les chances d'une fonction non existante est beaucoup plus élevé en raison de quelque chose qui se passe ailleurs dans le code.

Gardez à l'esprit que si vous ne déclenchez pas l'exception que vous n'avez pas déroulage ou retours en arrière dans le code. Dans l'exemple de la pêche n'exécutera si quelque chose est erroné (jQuery est manquant ou quelque chose comme ça), mais la si la méthode de déclaration a une évaluation qui se passe sur chaque appel à cette fonction - vous ne devriez pas faire plus de travail que vous devez .

Answer 6

Pour répondre directement à la question, comme tout le monde a, le try..catch va probablement être plus cher s'il est en fait une erreur.

Pour signaler quelques erreurs supplémentaires dans le code au-delà de ce que les autres ont déjà dit:

Ces deux codes ne sont pas du tout équivalent. Pour expliquer, même si les codes semblent faire exactement la même chose, ils ne le font pas.

Dans le cas de l'if () contrôle, aucun de code est exécutée. Dans le cas du gestionnaire d'exceptions, chaque ligne de code dans le gestionnaire d'exception est exécutée. SO, ce qui se passe si l'erreur se produit dans la deuxième ou la troisième ligne? Ensuite, vous avez quelque chose de complètement différent qui se passe dans votre code que ce que vous obtenez si vous vérifiez les conditions avant d'exécuter tout cela.

Answer 7

En dehors des réponses, je veux ajouter quelques réflexions à ce sujet.

Les exceptions qui sont imprévues, à savoir l'exécution renvoie une exception, ne doit pas être pris avec try ... catch parce que vous voulez lire le message qui est lancé dans la console.

try ... catch devrait être jeté OMI lorsqu'une exception se produit que votre application peut prévoir dans votre logique d'application et que vous souhaitez effectuer certaines actions personnalisées quand ils le font. C'est à dire. vous voulez être descriptif à ce sujet étant une exception, et il ne fait pas partie du flux heureux de la logique d'application.

Par exemple, vous pourriez avoir une méthode qui valide l'entrée d'utilisateur de sorte que vous pourriez avoir une méthode de isValid qui retourne un booléen dans ce cas, vous devez utiliser si ... alors.

D'autre part, si votre exécution d'un certain processus, et vous savez qu'une certaine exception peut se produire qui interrompt le flux heureux et que vous voulez gérer cela, je pense qu'il est préférable de jeter une exception.

Comme exemple abstrait, vous pourriez avoir des méthodes qui met en oeuvre des règles commerciales.
Au lieu de valider toutes les règles d'affaires pour la validité, vous pourriez avoir une exception personnalisée contenant des métadonnées dynamiques qui peuvent être jetés par chacune de ces méthodes lorsque la validité est violée et les traiter de manière appropriée, et continuer le flux heureux autrement.
Cela se traduirait par quelque chose comme:

throw new BusinessValidationException(TAG, 'Reason for the validation');

Quelle OMI est beaucoup plus descriptif que:

if (!checkValidityBusinessRule()) 
    // doSomething 

Pour une série de règles métier.

En ce qui concerne l'exemple, il est mon humble avis que cette vérification ne devrait pas se produire en premier lieu et que les chèques donnés sont exacts par défaut pour la mise en œuvre de la méthode.

if(typeof jQuery == 'function' && typeof nav == 'object' && typeof pageid != 'undefined' && typeof document.getElementById('leftnav') == 'object')

Ce que cela signifie est que vous devez déclarative assurer que les conditions sont vraies données avant d'appeler la méthode donnée avec des effets secondaires, emportant la nécessité d'effectuer les contrôles du tout.
S'il arrive que l'une des conditions est fausse, il lancera une exception à la console, qui est en fait ce que vous voulez, car en tant que développeur cela signifie que quelque chose dans votre logique de l'application ou du cycle de vie est brisée.

Mes 2 cents, j'espère qu'ils ont un sens.