Exception, classe
Représente les erreurs qui se produisent lors de l'exécution de l'application.
Espace de noms : System
Assembly : mscorlib (dans mscorlib.dll)
Syntaxe
'Déclaration
<SerializableAttribute> _
<ComVisibleAttribute(True)> _
<ClassInterfaceAttribute(ClassInterfaceType.None)> _
Public Class Exception
Implements ISerializable, _Exception
'Utilisation
Dim instance As Exception
[SerializableAttribute]
[ComVisibleAttribute(true)]
[ClassInterfaceAttribute(ClassInterfaceType.None)]
public class Exception : ISerializable, _Exception
[SerializableAttribute]
[ComVisibleAttribute(true)]
[ClassInterfaceAttribute(ClassInterfaceType::None)]
public ref class Exception : ISerializable, _Exception
/** @attribute SerializableAttribute() */
/** @attribute ComVisibleAttribute(true) */
/** @attribute ClassInterfaceAttribute(ClassInterfaceType.None) */
public class Exception implements ISerializable, _Exception
SerializableAttribute
ComVisibleAttribute(true)
ClassInterfaceAttribute(ClassInterfaceType.None)
public class Exception implements ISerializable, _Exception
Notes
Cette classe est la classe de base pour toutes les exceptions. Lorsqu'une erreur se produit, le système ou l'application en cours d'exécution la signale en levant une exception qui contient des informations sur l'erreur. Une fois levée, une exception est gérée par l'application ou par le gestionnaire d'exceptions par défaut.
Le Common Language Runtime fournit un modèle de gestion d'exceptions basé sur la représentation des exceptions sous forme d'objets ainsi que sur la séparation du code du programme et du code de gestion des exceptions en blocs try et en blocs catch, respectivement. Il peut y avoir un ou plusieurs blocs catch, chaque bloc étant destiné à gérer un type particulier d'exception, ou un seul bloc destiné à intercepter une exception plus spécifique qu'un autre bloc.
Si une application gère les exceptions qui se produisent lors de l'exécution d'un bloc de code de l'application, le code doit être placé dans une instruction try. Le code de l'application contenu dans une instruction try est un bloc try. Le code de l'application qui gère les exceptions levées par un bloc try est placé dans une instruction catch ; ce bloc est un bloc catch. Zéro ou plusieurs blocs catch sont associés à un bloc try et chaque bloc catch comporte un filtre de types qui détermine les types d'exceptions à gérer.
Lorsqu'une exception se produit dans un bloc try, le système recherche les blocs catch associés dans l'ordre dans lequel ils apparaissent dans le code de l'application, jusqu'à ce qu'il trouve un bloc catch qui gère l'exception en question. Un bloc catch gère une exception de type T si le filtre de types du bloc catch spécifie T ou tout autre type dont T dérive. Le système arrête la recherche après avoir trouvé le premier bloc catch qui gère l'exception. C'est pourquoi, dans le code de l'application, un bloc catch qui gère un type particulier doit être spécifié avant un bloc catch qui gère ses types de base, comme le montre l'exemple donné après cette section. Un bloc catch qui gère System.Exception est spécifié en dernier.
Si aucun des blocs catch associés au bloc try en cours ne gère l'exception concernée et que le bloc try en cours est imbriqué dans d'autres blocs try dans l'appel en cours, la recherche porte sur les blocs catch associés au bloc try englobant suivant. Si aucun bloc catch n'est trouvé pour gérer l'exception, le système effectue une recherche dans les niveaux d'imbrication précédents dans l'appel en cours. Si aucun bloc catch n'est trouvé pour l'exception dans l'appel en cours, l'exception remonte dans la pile des appels et la recherche d'un bloc catch qui gère l'exception est effectuée dans le frame de pile précédent. La recherche continue dans la pile des appels jusqu'à ce que l'exception soit gérée ou tant que des frames sont présents dans la pile des appels. Si le haut de la pile des appels est atteint sans qu'un bloc catch gérant l'exception n'ait été trouvé, le gestionnaire d'exceptions par défaut gère l'exception et l'application s'arrête.
Les types d'exceptions prennent en charge les fonctionnalités suivantes :
Texte explicite décrivant l'erreur. Lorsqu'une exception se produit, le runtime informe l'utilisateur par le biais d'un message textuel de la nature de l'erreur et suggère une action pour résoudre le problème. Ce message textuel est contenu dans la propriété Message de l'objet exception. Lors de la création de l'objet exception, vous pouvez passer au constructeur une chaîne textuelle qui décrit en détail cette exception particulière. Si aucun argument de message d'erreur n'est fourni au constructeur, le message d'erreur par défaut est utilisé.
État de la pile des appels lors de la levée de l'exception. La propriété StackTrace conserve une trace de la pile qui peut être utilisée pour déterminer l'endroit où l'erreur se produit dans le code. La trace de la pile répertorie toutes les méthodes appelées ainsi que les numéros de ligne, dans le fichier source, où les appels ont été réalisés.
Il existe deux catégories d'exceptions sous la classe de base Exception :
les classes d'exceptions prédéfinies du Common Language Runtime, dérivées de SystemException ;
les classes d'exceptions de l'application définies par l'utilisateur, dérivées de ApplicationException.
Exception inclut plusieurs propriétés qui permettent d'identifier l'emplacement du code, le type, le fichier d'aide et la raison de l'exception : StackTrace, InnerException, Message, HelpLink, HResult, Source, TargetSite et Data.
Lorsqu'une relation de causalité existe entre deux exceptions ou plus, la propriété InnerException conserve ces informations. L'exception externe est levée en réponse à cette exception interne. Le code qui gère l'exception externe peut utiliser les informations de l'exception interne antérieure pour gérer l'erreur de manière plus appropriée. Des informations supplémentaires sur l'exception peuvent être stockées dans la propriété Data.
La chaîne du message d'erreur passée au constructeur lors de la création de l'objet exception doit être localisée et peut être fournie à partir d'un fichier de ressources en utilisant ResourceManager. Pour plus d'informations sur la localisation des ressources, consultez la vue d'ensemble de l'espace de noms System.Resources et Empaquetage et déploiement de ressources.
Pour fournir à l'utilisateur des informations complètes sur la raison de la levée de l'exception, la propriété HelpLink peut contenir une URL (ou URN) pointant vers un fichier d'aide.
Exception utilise HRESULT COR_E_EXCEPTION, dont la valeur est 0x80131500.
Pour obtenir la liste des valeurs initiales des propriétés d'une instance de Exception, consultez les constructeurs Exception.
Considérations sur les performances
Une quantité importante de ressources système et de temps d'exécution est utilisée lorsque vous levez ou gérez une exception. Levez des exceptions uniquement pour gérer des conditions vraiment extraordinaires, et non pas pour gérer des événements ou un contrôle de flux prévisibles. Par exemple, votre application peut raisonnablement lever une exception si l'argument d'une méthode n'est pas valide, car vous voulez appeler votre méthode avec des paramètres valides. Un argument de méthode non valide signifie que quelque chose d'anormal s'est produit. Inversement, ne levez pas d'exception si l'entrée d'utilisateur n'est pas valide, car vous pouvez vous attendre à ce que les utilisateurs entrent parfois des données non valides. Dans ce cas, fournissez un mécanisme de nouvelle tentative pour permettre aux utilisateurs de corriger leur entrée.
Levez uniquement des exceptions pour des conditions anormales, interceptez les exceptions dans un gestionnaire d'exceptions à usage général qui s'applique à la plus grande part de votre application, et non dans un gestionnaire qui s'applique à une exception spécifique. Le raisonnement propre à cette approche est que la plupart des erreurs peuvent être gérées par validation et le code de gestion des erreurs à proximité de l'erreur ; aucune exception ne doit être levée ni interceptée. Le gestionnaire d'exceptions à usage général intercepte les exceptions vraiment inattendues, levées n'importe où dans l'application.
De plus, ne levez pas d'exception lorsqu'un code de retour est suffisant ; ne convertissez pas de code de retour en exception ; et n'interceptez pas régulièrement d'exception, ignorez-la, puis continuez le processus.
Exemple
L'exemple de code suivant illustre un bloc catch défini pour gérer les erreurs ArithmeticException. Ce bloc catch intercepte également les erreurs DivideByZeroException, car DivideByZeroException dérive de ArithmeticException et aucun bloc catch n'est défini explicitement pour les erreurs DivideByZeroException.
Imports System
Class ExceptionTestClass
Public Shared Sub Main()
Dim x As Integer = 0
Try
Dim y As Integer = 100 / x
Catch e As ArithmeticException
Console.WriteLine("ArithmeticException Handler: {0}", e.ToString())
Catch e As Exception
Console.WriteLine("Generic Exception Handler: {0}", e.ToString())
End Try
End Sub 'Main
End Class 'ExceptionTestClass
using System;
class ExceptionTestClass
{
public static void Main()
{
int x = 0;
try
{
int y = 100/x;
}
catch (ArithmeticException e)
{
Console.WriteLine("ArithmeticException Handler: {0}", e.ToString());
}
catch (Exception e)
{
Console.WriteLine("Generic Exception Handler: {0}", e.ToString());
}
}
}
using namespace System;
int main()
{
int x = 0;
try
{
int y = 100 / x;
}
catch ( ArithmeticException^ e )
{
Console::WriteLine( "ArithmeticException Handler: {0}", e );
}
catch ( Exception^ e )
{
Console::WriteLine( "Generic Exception Handler: {0}", e );
}
}
import System.*;
class ExceptionTestClass
{
public static void main(String[] args)
{
int x = 0;
try {
int y = 100 / x;
}
catch (ArithmeticException e) {
Console.WriteLine("ArithmeticException Handler: {0}", e.ToString());
}
catch (System.Exception e) {
Console.WriteLine("Generic Exception Handler: {0}", e.ToString());
}
} //main
} //ExceptionTestClass
Le code C# génère la sortie suivante :
ArithmeticException Handler: System.DivideByZeroException: Attempted to divide by zero. at ExceptionTestClass.Main()
Le code Visual Basic génère la sortie suivante :
ArithmeticException Handler: System.OverflowException: Exception of type System.OverflowException was thrown. at ExceptionTestClass.Main()
Hiérarchie d'héritage
System.Object
System.Exception
Classes dérivées
Sécurité des threads
Les membres statiques publics (Shared en Visual Basic) de ce type sont thread-safe. Il n'est pas garanti que les membres d'instance soient thread-safe.
Plates-formes
Windows 98, Windows 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile pour Pocket PC, Windows Mobile pour Smartphone, Windows Server 2003, Windows XP Édition Media Center, Windows XP Professionnel Édition x64, Windows XP SP2, Windows XP Starter Edition
Le .NET Framework ne prend pas en charge toutes les versions de chaque plate-forme. Pour obtenir la liste des versions prises en charge, consultez Configuration requise.
Informations de version
.NET Framework
Prise en charge dans : 2.0, 1.1, 1.0
.NET Compact Framework
Prise en charge dans : 2.0, 1.0
Voir aussi
Référence
Membres Exception
System, espace de noms
SystemException
ApplicationException, classe
Autres ressources
Gestion et levée des exceptions
Empaquetage et déploiement de ressources