Vue d'ensemble de la performance

Mise à jour : novembre 2007

La performance peut être un facteur clé dans un site Web ou projet réussi. Cette rubrique fournit des instructions pour l'amélioration de la performance d'un site ainsi que des liens vers les meilleures méthodes conseillées.

Cette rubrique contient les sections suivantes :

Meilleures pratiques
Contexte
Exemples de code

Meilleures pratiques

La liste suivante fournit des liens vers les ressources du site Web Microsoft qui décrivent des méthodes générales recommandées pour la performance des sites Web ASP.NET.

Retour au début

Contexte

La section répertorie des techniques que vous pouvez utiliser pour améliorer les performances des applications Web ASP.NET. Ces instructions sont réparties en différentes sections :

Traitement des pages et des contrôles serveur
Gestion d'état
Accès aux données
Applications Web
Méthodes de codage

Traitement des pages et des contrôles serveur

Les instructions suivantes proposent différents moyens d'utiliser les contrôles et les pages ASP.NET de façon efficace.

Évitez des allers-retours inutiles au serveur Dans certaines situations, vous pouvez utiliser ASP.NET AJAX et la restitution de page partielle pour accomplir des tâches dans le code du navigateur sans effectuer une publication (postback) complète. Par exemple, vous pouvez utiliser des fonctionnalités ASP.NET AJAX pour valider l'entrée de l'utilisateur dans le navigateur avant que l'entrée ne soit soumise au serveur. Pour plus d'informations, consultez Vue d'ensemble d'ASP.NET AJAX et Vue d'ensemble du rendu de page partielle.
En général, si vous n'avez pas besoin de transmettre au serveur des informations à vérifier ou à écrire dans un magasin de données, vous pouvez améliorer la performance de la page (et par conséquent, le travail de l'utilisateur) en évitant tout code qui provoque des allers-retours vers le serveur.
Si vous développez des contrôles serveur personnalisés, envisagez de les concevoir pour restituer le script client pour quelques-unes de leurs fonctionnalités. Cela peut réduire considérablement le nombre de fois que les informations sont envoyées au serveur Web. Pour plus d'informations, consultez Développement de contrôles serveur ASP.NET personnalisés et Création d'un script client personnalisé à l'aide de Microsoft AJAX Library.
Utilisez la propriété IsPostBack de l'objet Page pour éviter tout traitement inutile Évitez d'exécuter le code sur chaque publication (postback) s'il doit exécuter seulement la première fois que la page est demandée. Vous pouvez tester la propriété IsPostBack pour exécuter le code de façon conditionnelle, selon que la page est générée en réponse à un événement de contrôle serveur.
Laisser la mise en mémoire tampon activée, sauf si vous avez une raison spécifique de la désactiver La désactivation de la mise en mémoire tampon des pages Web ASP.NET possède un coût significatif en termes de performance. Pour plus d'informations, consultez la propriété Buffer.
Utilisez la méthode Transfer de l'objet Server ou la publication sur plusieurs pages pour faire des redirections entre des pages ASP.NET dans la même application Pour plus d'informations, consultez Redirection des utilisateurs vers une autre page.

Gestion des états

Les instructions suivantes proposent des solutions pour rendre la gestion d'état efficace.

N'enregistrez l'état d'affichage du contrôle serveur que si nécessaire L'état d'affichage permet aux contrôles serveur de compléter leurs valeurs de propriétés lors d'un aller-retour sans que vous deviez écrire la moindre ligne de code. Toutefois, l'état d'affichage affecte la performance et la taille de la page parce qu'il est passé vers et depuis le serveur dans un champ de formulaire caché. Si vous liez un contrôle serveur aux données lors de chaque aller-retour, l'état d'affichage enregistré n'est pas utile, parce que les valeurs du contrôle sont remplacées par les nouvelles valeurs pendant la liaison de données. Dans ce cas, la désactivation de l'état d'affichage économise le temps de traitement et réduit la taille de la page.

Par défaut, l'état d'affichage est activé pour tous les contrôles serveur. Pour le désactiver pour un contrôle, affectez à la propriété EnableViewState du contrôle la valeur false, comme dans l'exemple suivant :
```
<asp:datagrid EnableViewState="false" datasource="..." 
   />
```
Vous pouvez également désactiver l'état d'affichage pour une page en utilisant la directive @ Page, comme le montre l'exemple suivant :
```
<%@ Page EnableViewState="false" %>
```
Cela est utile lorsque la page ne requiert pas de traitement de publication (postback).

Remarque :

L'attribut EnableViewState est également pris en charge dans la directive @ Control pour spécifier si l'état d'affichage est activé pour un contrôle utilisateur.

Pour analyser la taille de l'état d'affichage pour une page, activez le traçage pour la page en affectant la valeur trace="true" à la directive @ Page. Dans la sortie de trace, examinez la colonne Viewstate du tableau Hiérarchie des contrôles. Pour plus d'informations, consultez Vue d'ensemble du traçage ASP.NET.
Évitez d'utiliser le chiffrement de l'état d'affichage à moins d'y être obligé Le chiffrement de l'état d'affichage empêche les utilisateurs de lire les valeurs de l'état d'affichage dans le champ de formulaire de l'état d'affichage masqué. Par exemple, vous pouvez chiffrer l'état d'affichage si une page inclut un contrôle GridView qui gère un champ d'identificateur dans la propriété DataKeyNames afin de coordonner les mises à jour aux enregistrements. Vous pouvez chiffrer l'état d'affichage lorsque vous ne souhaitez pas que les utilisateurs puissent voir l'identificateur. Toutefois, le chiffrement présente un coût constant en termes de performance pour l'initialisation et un coût supplémentaire qui dépend de la taille de l'état d'affichage à chiffrer. Le chiffrement est effectué chaque fois que la page est chargée. Par conséquent, la même incidence se produit sur la performance lorsque la page est demandée pour la première fois et pendant chaque publication (postback).

Remarque :
L'attribut EnableViewState est également pris en charge dans la directive @ Control pour spécifier si l'état d'affichage est activé pour un contrôle utilisateur.

Désactivez l'état de session lorsque vous ne l'utilisez pas Pour désactiver l'état de session pour une page, affectez à l'attribut EnableSessionState de la directive @ Page la valeur false, comme dans l'exemple suivant :

<%@ Page EnableSessionState="false" %>

Remarque :
Si une page requiert l'accès aux variables de session, mais ne les crée pas ou ne les modifie pas, définissez l'attribut EnableSessionState de la directive @ Page avec la valeur ReadOnly.

Vous pouvez aussi désactiver l'état de session pour les méthodes de services Web ASP.NET. Pour plus d'informations, consultez Vue d'ensemble des services d'application ASP.NET.

Pour désactiver l'état de session pour une application, définissez l'attribut Mode avec la valeur Off dans la section SessionState du fichier Web.config de l'application, comme dans l'exemple suivant :

<sessionState mode="Off" />

Choisissez le fournisseur d'états de session approprié pour votre application ASP.NET offre plusieurs moyens de stocker des données de session pour votre application. Ceux-ci incluent l'état de session in-process, l'état de session out-of-process en tant que service Windows, et l'état de session out-of-process dans une base de données SQL Server. (Vous pouvez aussi créer un fournisseur d'états de session personnalisé pour stocker les données de session dans un magasin de données de votre choix.) Chaque solution présente ses avantages, mais l'état de session in-process est de loin la solution la plus rapide. Si vous utilisez uniquement l'état de session pour de petites quantités de données dans l'état de session, utilisez le fournisseur in-process. Utilisez des options d'état de session out-of-process si vous mettez à l'échelle votre application à travers plusieurs processeurs ou à travers plusieurs ordinateurs, ou si vous souhaitez rendre des données de session persistantes lorsqu'un serveur ou un processus est redémarré. Pour plus d'informations, consultez Vue d'ensemble de l'état de session ASP.NET.

Accès aux données

Les instructions suivantes proposent des solutions pour rendre efficace l'accès aux données de votre application.

Utilisez SQL Server et des procédures stockées pour l'accès aux données SQL Server est le choix recommandé pour le stockage des données pour créer des applications Web hautes performances et évolutives. Lorsque vous utilisez le fournisseur SQL Server managé, vous pouvez obtenir un gain de performance supplémentaire en utilisant chaque fois que possible des procédures stockées compilées à la place des commandes SQL. Pour plus d'informations, consultez Configuration des paramètres et des types de données de paramètre (ADO.NET).
Utilisez la classe SqlDataReader pour un curseur de données rapide avant uniquement La classe SqlDataReader crée un flux de données avant uniquement en lecture seul récupéré depuis une base de données SQL Server. La classe SqlDataReader utilise le format natif de transfert de données réseau de SQL Server pour lire directement les données à partir d'une connexion de base de données. Si possible, utilisez la classe SqlDataReader, parce qu'elle offre de meilleures performances que la classe DataSet. Par exemple, lorsque vous liez un contrôle de données au contrôle SqlDataSource, vous obtenez de meilleures performances si vous affectez à la propriété DataSourceMode la valeur DataReader. (Toutefois, un lecteur de données prend en charge moins de fonctionnalités que le mode DataSet.) La classe SqlDataReader implémente l'interface IEnumerable, qui vous permet de lier des contrôles serveur. Pour plus d'informations, consultez la classe SqlDataReader et Accès aux données avec ASP.NET.
Mettez en cache les données et sorties de pages dès que possible Utilisez la mise en cache ASP.NET si les pages ou les données doivent être calculées dynamiquement pour chaque demande de page. Si possible, concevez des pages et des demandes de données compatibles avec la mise en cache, surtout dans les situations dans lesquelles vous attendez un fort trafic. Une utilisation appropriée du cache peut améliorer la performance de votre site bien plus que l'utilisation de toute autre fonctionnalité du .NET Framework.

Lorsque vous utilisez la mise en cache ASP.NET, suivez ces instructions. En premier lieu, ne mettez pas trop d'éléments en cache, parce que chaque élément mis en cache utilise la mémoire du serveur. Par exemple, ne mettez pas en cache des éléments qui sont recalculés facilement ou utilisés rarement. En second lieu, n'affectez pas aux éléments mis en cache un délai d'expiration bref. Les éléments qui expirent rapidement peuvent générer du travail supplémentaire pour le code de nettoyage et pour le garbage collector. Vous pouvez surveiller le roulement dans le cache consécutif à l'expiration d'éléments à l'aide du compteur de performance Taux de rendement total du cache associé à l'objet de performance Applications ASP.NET. Un taux de rendement élevé peut indiquer un problème, en particulier si des éléments sont supprimés avant leur expiration. (Cette situation est quelquefois connue sous le nom de sollicitation de la mémoire.)

Pour plus d'informations sur la façon de mettre en cache les sorties de page et les demandes de données, consultez Vue d'ensemble de la mise en cache ASP.NET.
Utilisez convenablement la dépendance de cache SQL Pour la mise en cache des données à partir de SQL Server, ASP.NET prend en charge l'interrogation basée sur des tables et la notification de requête, selon la version de SQL Server que vous utilisez. L'interrogation basée sur des tables est prise en charge par toutes les versions de SQL Server. Dans l'interrogation basée sur des tables, si des données changent dans une table, tous les éléments du cache qui dépendent de la table sont invalidés. Cela peut provoquer un roulement inutile dans le cache. L'interrogation basée sur des tables n'est pas recommandée pour les tables dont les éléments sont souvent modifiés. Par exemple, l'interrogation basée sur des tables est recommandée pour une table de catalogue rarement modifiée. Elle n'est pas recommandée pour une table de commandes fréquemment mise à jour.

La notification de requête est prise en charge par SQL Server 2005 et les versions ultérieures. La notification de requête utilise des requêtes SQL pour détecter des modifications dans un jeu de lignes ciblé. Cela réduit le nombre de notifications envoyées lorsqu'une table est modifiée. La notification de requête peut fournir de meilleures performances que l'interrogation basée sur des tables. Toutefois, elle n'est pas adaptée à des milliers de requêtes.

Pour plus d'informations sur la dépendance de cache SQL, consultez Procédure pas à pas : utilisation de la mise en cache de sortie ASP.NET avec SQL Server et Mise en cache dans ASP.NET avec la classe SqlCacheDependency.
**Utilisez la pagination et le tri de la source de données plutôt que la pagination et le tri de l'interface utilisateur **La fonctionnalité de pagination de l'interface utilisateur pour les contrôles de données, tels que DetailsView et GridView, peut être utilisée avec n'importe quel objet source de données qui prend en charge l'interface ICollection. Pour chaque opération de pagination, le contrôle de données interroge la source de données pour la collection de données entière et sélectionne la ou les lignes à afficher, en ignorant le reste des données.

Si un contrôle de source de données implémente DataSourceView et si la propriété CanPage retourne la valeur true, le contrôle de données utilise la pagination de la source de données plutôt que la pagination de l'interface utilisateur. Dans ce cas, le contrôle de données demande uniquement les lignes requises pour chaque page à afficher. Par conséquent, la pagination de la source de données est plus efficace que la pagination de l'interface utilisateur. Parmi les contrôles ASP.NET standard, seuls les contrôles de source de données ObjectDataSource et LinqDataSource prennent en charge la pagination de la source de données. Pour activer la pagination de la source de données pour d'autres contrôles de source de données, vous pouvez hériter du contrôle de source de données que vous souhaitez utiliser, puis modifier son comportement.
Utilisez une colonne Timestamp pour le contrôle concurrentiel avec le contrôle LinqDataSource Si une table de base de données SQL Server ne contient pas de colonne Timestamp (un type de données SQL Server), le contrôle LinqDataSource vérifie l'accès concurrentiel aux données en stockant les valeurs de données d'origine dans la page Web. LINQ to SQL vérifie les valeurs d'origine par rapport à la base de données avant de mettre à jour les données ou de les supprimer. Cette approche peut créer une page Web volumineuse si l'enregistrement de données contient de nombreuses colonnes ou d'importantes valeurs de colonne. Il peut également représenter un problème de sécurité si l'enregistrement contient des données que vous ne souhaitez pas exposer dans la page. Lorsqu'une table de base de données a une colonne Timestamp, le contrôle LinqDataSource stocke uniquement la valeur d'horodatage pour de futures comparaisons. LINQ to SQL peut vérifier la cohérence des données en déterminant si l'horodatage d'origine correspond à la valeur d'horodatage actuelle dans la table. Pour plus d'informations sur WMI, consultez timestamp (Transact-SQL) (en anglais) sur le site Web MSDN.

**Équilibrer l'avantage de la validation d'un événement en termes de sécurité avec son coût de performances **Les contrôles qui dérivent des classes System.Web.UI.WebControls et System.Web.UI.HtmlControls peuvent confirmer qu'un événement provient de l'interface utilisateur qui a été restituée par le contrôle. Cela permet d'empêcher le contrôle de répondre à une notification d'événement usurpée. Par exemple, en utilisant la validation d'événement, le contrôle DetailsView peut empêcher un utilisateur malveillant de faire un appel à la fonction Delete (qui n'est pas prise en charge, par nature, dans le contrôle) et de manipuler le contrôle afin de supprimer des données. La validation d'événement a un coût en termes de performance. Vous pouvez contrôler la validation d'événement à l'aide de l'élément de configuration EnableEventValidation et de la méthode RegisterForEventValidation. Le coût de la validation dépend du nombre de contrôles sur la page et est de l'ordre de quelques pour cent.

Note de sécurité :
Il est fortement recommandé de ne pas désactiver la validation des événements. Avant de le faire, assurez-vous qu'aucune publication (postback) pouvant avoir un effet involontaire sur votre application ne puisse être construite.

Utilisez la mise en cache, le tri et le filtrage du contrôle SqlDataSource Si la propriété DataSourceMode du contrôle SqlDataSource a la valeur DataSet, le contrôle SqlDataSource est capable de mettre en cache le jeu de résultats d'une requête. Les opérations de filtrage et de tri du contrôle SqlDataSource peuvent ensuite utiliser les données mises en mémoire cache. Une application peut s'exécuter plus vite si vous mettez en cache le groupe de données entier et si vous utilisez les propriétés FilterExpression et SortParameterName pour trier et filtrer. Le contrôle de source de données peut éviter de faire ensuite des requêtes SQL avec des clauses Where et Sort By pour accéder à la base de données chaque fois que les utilisateurs trient ou filtrent des données dans l'interface utilisateur.

Applications Web

Les instructions suivantes proposent des solutions pour que vos applications Web fonctionnent efficacement comme un tout.

Précompilez le site Une application Web est compilée par lots lors la première demande d'une ressource, telle qu'une page Web ASP.NET. Si aucune page de l'application n'a été compilée, la compilation par lots compile toutes les pages du répertoire en segments pour améliorer l'utilisation du disque et de la mémoire. Vous pouvez utiliser l'outil de compilation ASP.NET (Aspnet_compiler.exe) pour précompiler une application Web. Dans le cadre d'une compilation sur place, l'outil de compilation appelle le runtime ASP.NET pour compiler le site de la même manière que lorsqu'un utilisateur demande une page du site Web. Vous pouvez précompiler une application Web afin que le balisage de l'interface utilisateur soit conservé ou précompiler les pages afin que le code source ne puisse pas être modifié. Pour plus d'informations, consultez Comment : précompiler des sites Web ASP.NET.
Désactivez le mode débogage Désactivez toujours le mode débogage avant de déployer une application de production ou de mener des évaluations de performance. Si le mode débogage est activé, la performance de votre application peut s'en ressentir. Pour plus d'informations sur la configuration du mode débogage, consultez Modification des fichiers de configuration ASP.NET.
Réglez les fichiers de configuration pour l'ordinateur serveur Web et pour les applications spécifiques La configuration par défaut pour ASP.NET active le jeu le plus large de fonctionnalités et les scénarios les plus courants. Vous pouvez modifier certains paramètres de configuration par défaut pour améliorer la performance de vos applications, selon les fonctionnalités que vous utilisez. La liste suivante inclut les modifications de configuration à envisager :
- Activer uniquement l'authentification pour les applications qui la nécessitent Par défaut, le mode d'authentification pour les applications ASP.NET est Windows, ou NTLM intégré. Dans la plupart des cas, il est préférable de désactiver l'authentification dans le fichier Machine.config et de l'activer dans les fichiers Web.config des seules applications qui la requièrent.
- Configurez votre application pour qu'elle utilise les paramètres appropriés de codage des demandes et des réponses Par défaut, le codage d'ASP.NET est UTF-8. Si votre application utilise uniquement des caractères ASCII, configurez votre application en conséquence pour obtenir une légère amélioration de la performance.
- Désactivez AutoEventWireup pour votre application Affecter à l'attribut AutoEventWireup la valeur false dans le fichier Web.config empêche la page de lier des événements de page aux méthodes basées sur une correspondance de nom (par exemple, Page_Load). Vous pouvez obtenir un léger gain de performance pour vos pages. Pour gérer des événements de page, utilisez l'une de ces deux stratégies. La première stratégie consiste à substituer les méthodes. Par exemple, vous pouvez substituer la méthode OnLoad de l'objet Page pour écrire le code pour l'événement de chargement de la page. (Assurez-vous d'appeler la méthode de base pour que tous les événements soient déclenchés.) La seconde stratégie consiste à créer une liaison avec les événements de page à l'aide du mot clé Handles en Visual Basic ou en utilisant le rattachement délégué en C#.
- Supprimez les modules inutilisés du pipeline de traitement de demande Par défaut, toutes les fonctionnalités demeurent actives dans le nœud HttpModules du fichier Machine.config de votre serveur Web. En fonction des fonctionnalités utilisées par votre application, vous pouvez supprimer les modules inutilisés du pipeline de demande pour obtenir une légère amélioration de la performance. Examinez chaque module avec ses fonctionnalités et personnalisez-le en fonction de vos besoins. Par exemple, si vous n'utilisez pas l'état de session et la mise en cache des sorties dans votre application, vous pouvez supprimer les modules de ces fonctionnalités dans la liste HttpModules.
Exécutez des applications Web out-of-process sur les services IIS (Internet Information Services) 5.0 Par défaut, ASP.NET sur les services IIS 5.0 répond aux demandes à l'aide d'un processus de travail out-of-process. Cette fonctionnalité a été réglée pour un débit rapide. Du fait des nombreux avantages et fonctionnalités de l'exécution de ASP.NET dans un processus de travail out-of-process, cette solution est recommandée pour les sites de production.
Recycler régulièrement les processus Vous devez régulièrement recycler les processus, à la fois pour la stabilité et les performances. Sur les longues périodes de temps, les ressources comportant des fuites de mémoire et des bogues peuvent affecter le débit du serveur Web, et le recyclage des processus nettoie la mémoire de ces types de problèmes. Toutefois, vous devez trouver le juste équilibre entre un recyclage régulier et un recyclage trop fréquent, car les coûts liés à l'arrêt du processus de travail, au rechargement des pages et à l'obtention réitérée des ressources et des données peuvent annuler les avantages du recyclage.

Les applications Web ASP.NET qui s'exécutent sur Windows Server 2003 et les services IIS 6.0 ne requièrent pas de réglage du modèle de processus, parce qu'ASP.NET utilisera les paramètres du modèle de processus des services IIS 6.0.

Configurez correctement le nombre de threads par processus de travail pour votre application L'architecture des demandes d'ASP.NET tente de trouver un équilibre entre le nombre de threads qui exécutent des demandes et les ressources disponibles. L'architecture n'autorise pas l'exécution de plus de demandes simultanées qu'il n'y a de puissance UC disponible. Cette technique est appelée déclenchement périodique de thread. Il existe toutefois des conditions dans lesquelles l'algorithme de déclenchement périodique de thread ne fonctionne pas bien. Vous pouvez surveiller le déclenchement périodique de threads dans l'Analyseur de performances Windows à l'aide du compteur de performance Nombre d'instances de pipeline associé à l'objet de performance Applications ASP.NET.

Lorsqu'une page Web ASP.NET appelle une ressource externe, comme lorsqu'elle accède à une base de données ou traite des demandes de services Web ASP.NET, la demande de page s'interrompt en général jusqu'à ce que la ressource externe réponde. Cela libère l'UC pour traiter d'autres threads. Si une demande attend d'être traitée et qu'un thread du pool est libre, le traitement de la demande en attente commence. Le résultat peut être un nombre élevé de demandes s'exécutant de façon simultanée et de threads en attente dans le processus de travail ASP.NET ou le pool d'applications. Cela peut entraîner un ralentissement du débit du serveur Web et une dégradation des performances.

Pour limiter cet effet sur les performances, vous pouvez définir manuellement la limite du nombre de threads dans le processus. Pour cela, modifiez les attributs MaxWorkerThreads et MaxIOThreads dans la section processModel du fichier Machine.config.

Remarque :
Les threads de travail sont destinés au traitement des demandes ASP.NET, tandis que les threads d'E/S sont utilisés pour fournir des données issues de fichiers, de bases de données ou de services Web ASP.NET.

Les valeurs que vous affectez aux attributs du modèle de processus représentent le nombre maximal de chaque type de thread par UC dans le processus. Pour un ordinateur à deux processeurs, le nombre maximal est égal au double de la valeur définie. Pour un ordinateur de quatre processeurs, ce nombre est égal à quatre fois la valeur définie. Les paramètres par défaut sont adaptés aux ordinateurs à un processeur et aux ordinateurs à deux processeurs. Toutefois, 100 ou 200 threads dans le processus pour les ordinateurs qui ont plus de deux processeurs peuvent réduire les performances. S'il y a trop de threads dans un processus, il peut ralentir. Le serveur doit exécuter des commutateurs de contexte supplémentaires, ce qui fait que le système d'exploitation consomme des cycles d'UC pour la maintenance de ces threads au lieu de traiter les demandes. Vous pouvez déterminer le nombre approprié de threads en testant les performances de votre application.

Pour les applications qui reposent largement sur des ressources externes, activez le jardinage Web sur les ordinateurs multiprocesseurs Le modèle de processus ASP.NET facilite l'activation de l'évolutivité sur les ordinateurs multiprocesseurs en répartissant le travail entre plusieurs processus, un par UC, chacun ayant une affinité de processeur définie avec une UC. Cette technique est parfois appelée le jardinage Web. Les applications Web peuvent bénéficier du jardinage Web si elles utilisent de nombreuses ressources externes. Par exemple, les applications peuvent en bénéficier si elles utilisent un serveur de base de données ou si elles appellent des objets COM qui ont des dépendances externes. Toutefois, testez la performance d'une application Web dans un jardin Web avant d'activer le jardinage Web pour un site Web de production.

Méthodes de codage

Les instructions suivantes proposent des solutions pour écrire un code efficace.

Ne comptez pas sur les exceptions dans votre code Les exceptions peuvent entraîner une forte diminution des performances. Par conséquent, évitez de les utiliser pour contrôler le flux normal du programme. Si possible, incluez une logique dans votre code pour détecter et gérer les conditions qui provoqueraient une exception. Les scénarios courants de détection dans le code incluent le contrôle de null, en analysant des chaînes en valeurs numériques, et le contrôle de valeurs spécifiques avant d'appliquer des opérations mathématiques. L'exemple suivant illustre du code qui pourrait provoquer une exception et du code de substitution qui teste une condition. Les deux génèrent le même résultat.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```