Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
L’une des préoccupations courantes liées aux exceptions est que si des exceptions sont utilisées pour le code qui échoue régulièrement, les performances de l’implémentation sont inacceptables. Cette inquiétude est tout à fait valide. Lorsqu’un membre lève une exception, ses performances peuvent être ralenties de plusieurs ordres de grandeur. Toutefois, il est possible d’obtenir de bonnes performances tout en respectant strictement les instructions d’exception qui interdisent l’utilisation de codes d’erreur. Deux modèles décrits dans cette section suggèrent des façons de procéder.
❌ N’utilisez PAS de codes d’erreur par crainte que les exceptions affectent négativement les performances.
Pour améliorer les performances, il est possible d’utiliser le modèle Tester-Doer ou le modèle Try-Parse, décrit dans les deux sections suivantes.
Modèle Tester-Doer
Parfois, les performances d’un membre qui lève une exception peuvent être améliorées en divisant le membre en deux. Examinons la Add méthode de l’interface ICollection<T> .
ICollection<int> numbers = ...
numbers.Add(1);
La méthode Add lève si la collection est en lecture seule. Il peut s’agir d’un problème de performances dans les scénarios où l’appel de méthode est censé échouer souvent. L’une des façons d’atténuer le problème consiste à tester si la collection est accessible en écriture avant d’essayer d’ajouter une valeur.
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
Le membre utilisé pour tester une condition, qui dans notre exemple est la propriété IsReadOnly, est appelée testeur. Le membre utilisé pour effectuer une opération susceptible de lever une exception, la méthode Add dans notre exemple, est appelé exécutant.
✔️ CONSIDÉREZ le modèle Tester-Doer pour les membres susceptibles de lever des exceptions dans des scénarios courants afin d’éviter les problèmes de performances liés aux exceptions.
Modèle Try-Parse
Pour les API extrêmement sensibles aux performances, un modèle encore plus rapide que le modèle de Tester-Doer décrit dans la section précédente doit être utilisé. Le modèle appelle à ajuster le nom du membre pour qu’un cas de test bien défini fasse partie de la sémantique du membre. Par exemple, DateTime définit une méthode qui lève une Parse exception si l’analyse d’une chaîne échoue. Il définit également une méthode correspondante TryParse qui tente d’analyser, mais retourne false si l’analyse échoue et retourne le résultat d’une analyse réussie à l’aide d’un out paramètre.
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
Lorsque vous utilisez ce modèle, il est important de définir la fonctionnalité try en termes stricts. Si le membre échoue pour une raison autre que la tentative bien définie, le membre doit toujours lever une exception correspondante.
✔️ CONSIDÉREZ le modèle Try-Parse pour les membres susceptibles de lever des exceptions dans des scénarios courants afin d’éviter les problèmes de performances liés aux exceptions.
✔️ Utilisez le préfixe « Try » et le type de retour booléen pour les méthodes implémentant ce modèle.
✔️ Fournit un membre générant une exception pour chaque membre à l’aide du modèle Try-Parse.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.