Cet article a fait l'objet d'une traduction automatique. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.

Traduction

Source

1 sur 1 ont trouvé cela utile - Évaluez ce sujet

Exception, classe

.NET Framework 4.5

Autres versions

Représente les erreurs qui se produisent lors de l'exécution de l'application.

Hiérarchie d'héritage

System.Object
System.Exception
En savoir plus...

Espace de noms : System
Assembly : mscorlib (dans mscorlib.dll)

Syntaxe

C++

[SerializableAttribute]
[ComVisibleAttribute(true)]
[ClassInterfaceAttribute(ClassInterfaceType.None)]
public class Exception : ISerializable, _Exception

Le type Exception expose les membres suivants.

Constructeurs

	Nom	Description
	Exception()	Initialise une nouvelle instance de la classe Exception.
	Exception(String)	Initialise une nouvelle instance de la classe Exception avec un message d'erreur spécifié.
	Exception(SerializationInfo, StreamingContext)	Initialise une nouvelle instance de la classe Exception avec des données sérialisées.
	Exception(String, Exception)	Initialise une nouvelle instance de la classe Exception avec un message d'erreur spécifié et une référence à l'exception interne qui est à l'origine de cette exception.

Début

Propriétés

	Nom	Description
	Data	Obtient une collection de paires clé/valeur qui fournissent des informations supplémentaires définies par l'utilisateur sur l'exception.
	HelpLink	Obtient ou définit un lien vers le fichier d'aide associé à cette exception.
	HResult	Obtient ou définit HRESULT, valeur numérique codée qui est assignée à une exception spécifique.
	InnerException	Obtient l'instance Exception qui a provoqué l'exception actuelle.
	Message	Obtient un message qui décrit l'exception actuelle.
	Source	Obtient ou définit le nom de l'application ou de l'objet qui est à l'origine de l'erreur.
	StackTrace	Obtient une représentation sous forme de chaîne des frames immédiates sur la pile des appels.
	TargetSite	Obtient la méthode qui lève l'exception actuelle.

Début

Méthodes

	Nom	Description
	Equals(Object)	Détermine si l'objet spécifié est identique à l'objet actuel. (Hérité de Object.)
	Finalize	Autorise un objet à tenter de libérer des ressources et d'exécuter d'autres opérations de nettoyage avant qu'il ne soit récupéré par l'opération garbage collection. (Hérité de Object.)
	GetBaseException	En cas de substitution dans une classe dérivée, retourne Exception qui est à l'origine d'une ou de plusieurs exceptions suivantes.
	GetHashCode	Sert de fonction de hachage pour un type particulier. (Hérité de Object.)
	GetObjectData	En cas de substitution dans une classe dérivée, définit SerializationInfo avec des informations sur l'exception.
	GetType	Obtient le type au moment de l'exécution de l'instance actuelle. Dans XNA Framework 3.0, ce membre est hérité de Object.GetType(). Dans Bibliothèque de classes portable Bibliothèque de classes portable, ce membre est hérité de Object.GetType(). Dans .NET pour les applications du Windows Store Windows 8, ce membre est hérité de Object.GetType().
	MemberwiseClone	Crée une copie superficielle de l'objet Object actuel. (Hérité de Object.)
	ToString	Crée et retourne une chaîne représentant l'exception en cours. (Substitue Object.ToString().)

Début

Événements

	Nom	Description
	SerializeObjectState	Se produit lorsqu'une exception est sérialisée pour créer un objet d'état d'exception qui contient des données sérialisées relatives à l'exception.

Début

Notes

Cette classe est la classe de base pour toutes les exceptions. Quand une erreur se produit, le système ou l'application en cours d'exécution la signale en levant une exception contenant des informations sur l'erreur. Une fois levée, l'exception est gérée par l'application ou le gestionnaire d'exceptions par défaut.

Blocs try-catch

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.

Fonctionnalités des types d'exceptions

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.

Catégories des types d'exceptions

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.

Propriétés de classe d'exception

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 dans des applications de bureau.

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 une 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.

Exemples

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.

C++


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());
         }
   }	
}
/*
This code example produces the following results:

ArithmeticException Handler: System.DivideByZeroException: Attempted to divide by zero.
   at ExceptionTestClass.Main()

*/

Informations de version

.NET Framework

Pris en charge dans : 4.5, 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Pris en charge dans : 4, 3.5 SP1

Bibliothèque de classes portable

Pris en charge dans : Bibliothèque de classes portable

.NET pour les applications du Windows Store

Pris en charge dans : Windows 8

Plateformes

Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (rôle principal du serveur non pris en charge), Windows Server 2008 R2 (rôle principal du serveur pris en charge avec SP1 ou version ultérieure ; Itanium non pris en charge)

Le .NET Framework ne prend pas en charge toutes les versions de chaque plateforme. Pour obtenir la liste des versions prises en charge, consultez Configuration requise du .NET Framework.

Sécurité des threads

Tous les membres static (Shared en Visual Basic) publics de ce type sont thread-safe. Il n'est pas garanti que les membres d'instance soient thread-safe.

Voir aussi

Référence

System, espace de noms

SystemException

ApplicationException

Autres ressources

Gestion et levée des exceptions

Empaquetage et déploiement de ressources dans des applications de bureau

Hiérarchie d'héritage

Cela vous a-t-il été utile ? Oui Non

Manque de précision

Pas suffisamment approfondi

Besoin d'exemples de code supplémentaires

La traduction a besoin d'être améliorée.

(1500 caractères restants)

Ajouts de la communauté

AJOUTER