Pourquoi les blocs d'essai sont-ils chers ?

Question

J'ai entendu dire qu'il fallait éviter les blocs d'essai si possible, car ils sont chers.

Ma question porte spécifiquement sur la plate-forme .NET : Pourquoi les blocs try sont-ils chers ?

Résumé des réponses :

Il y a clairement deux camps sur cette question : ceux qui disent que les blocs d'essai sont chers, et ceux qui disent "peut-être un tout petit peu".

Ceux qui disent que les blocs d'essai sont coûteux mentionnent généralement le "coût élevé" du déroulement de la pile d'appels. Personnellement, je ne suis pas convaincu par cet argument, surtout après avoir lu comment les gestionnaires d'exceptions sont stockés. aquí .

Jon Skeet se situe dans le camp des "peut-être un tout petit peu", et a écrit deux articles sur les exceptions et les performances que vous pouvez trouver à l'adresse suivante aquí .

Il y a un article que j'ai trouvé extrêmement intéressant : il parle des "autres" implications des blocs d'essai sur les performances (pas nécessairement la consommation de mémoire ou de processeur). Peter Ritchie mentionne qu'il a constaté que le code à l'intérieur des blocs d'essai n'est pas optimisé comme il le serait autrement par le compilateur. Vous pouvez lire ses conclusions aquí .

Enfin, l'homme qui a implémenté les exceptions dans le CLR a publié un article de blog sur le sujet. Jetez un coup d'œil à l'article de Chris Brumme. aquí .

Answer 1

Les articles suivants devraient vous éclairer sur le sujet :

Les blocs try...catch nuisent-ils aux performances d'exécution ?

Implications des try/catch/finally en termes de performances

Answer 2

Ce n'est pas le bloc lui-même qui est cher, et ce n'est même pas attraper une exception, en soi, qui est coûteuse, c'est le runtime qui déroule la pile d'appels jusqu'à ce qu'il trouve un cadre de pile qui peut gérer l'exception. Lancer une exception est plutôt léger, mais si le runtime doit remonter six cadres de pile (c'est-à-dire six appels de méthode) pour trouver un gestionnaire d'exception approprié, en exécutant éventuellement des finally blocks au fur et à mesure, le temps passé peut être considérable.

Answer 3

Vous ne devriez pas éviter les blocs try/catch, car cela signifie généralement que vous ne traitez pas correctement les exceptions qui peuvent se produire. Le traitement structuré des exceptions (SEH) n'est coûteux que lorsqu'une exception se produit réellement, car le runtime doit parcourir la pile d'appels à la recherche d'un gestionnaire de capture, exécuter ce gestionnaire (et il peut y en avoir plusieurs), puis exécuter les blocs finally, et enfin rendre le contrôle au code au bon endroit.

Les exceptions ne sont pas destinées à être utilisées pour contrôler la logique du programme, mais plutôt pour indiquer des conditions d'erreur.

L'une des plus grandes idées fausses sur les exceptions est qu'elles sont destinées à "conditions exceptionnelles". La réalité est qu'elles servent à communiquer des conditions d'erreur. Du point de vue de la conception conception du framework, il n'existe pas de une "condition exceptionnelle". Le caractère exceptionnel ou non d'une condition dépend du contexte d'utilisation, --- mais les bibliothèques réutilisables savent rarement comment elles seront utilisées. Par exemple, OutOfMemoryException pourrait être exceptionnelle pour une simple application de saisie de données ; ce n'est pas si exceptionnel pour les applications qui font leur propre gestion de la mémoire (par exemple, le serveur SQL). En d'autres termes, l'exception d'un homme d'un homme est la condition chronique d'un autre chronique. [http://blogs.msdn.com/kcwalina/archive/2008/07/17/ExceptionalError.aspx]

Answer 4

Un bloc d'essai n'est pas cher du tout. Il ne coûte rien ou presque, sauf si une exception est levée. Et si une exception a été levée, c'est une exceptionnel circonstance et vous ne vous souciez plus des performances. Est-ce important que votre programme mette 0,001 seconde ou 1,0 seconde à tomber ? Non, cela n'a pas d'importance. Ce qui compte, c'est la qualité des informations qui vous sont transmises afin que vous puissiez corriger le problème et éviter qu'il ne se reproduise.

Answer 5

Je pense que les gens surestiment vraiment le coût en termes de performances de la levée d'exceptions. Oui, il y a un impact sur les performances, mais il est relativement minime.

J'ai effectué le test suivant, en lançant et en rattrapant un million d'exceptions. Cela a pris environ 20 secondes sur mon processeur Intel Core 2 Duo 2,8 GHz. C'est environ 50 000 exceptions par seconde. Si vous lancez ne serait-ce qu'une petite fraction de ça, vous avez des problèmes d'architecture.

Voici mon code :

using System;
using System.Diagnostics;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Stopwatch sw = Stopwatch.StartNew();
            for (int i = 0; i < 1000000; i++)
            {
                try
                {
                    throw new Exception();
                }
                catch {}
            }
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.Read();
        }
    }
}