Création et levée d'exceptions (Guide de programmation C#)
Les exceptions sont utilisées pour indiquer qu'une erreur s'est produite pendant l'exécution du programme. Les objets exception qui décrivent une erreur sont créés puis levés avec le mot clé throw. Le runtime recherche ensuite le gestionnaire d'exceptions le plus compatible.
Les programmeurs doivent lever des exceptions lorsqu'une ou plusieurs des conditions suivantes est vraie :
La méthode ne peut pas réaliser sa fonctionnalité définie.
Par exemple, si un paramètre de méthode possède une valeur non valide :
static void CopyObject(SampleClass original) { if (original == null) { throw new System.ArgumentException("Parameter cannot be null", "original"); } }Un appel inapproprié à un objet est fait, suivant l'état de l'objet.
Par exemple, en tentant d'écrire dans un fichier en lecture seule. Dans les cas où un état d'objet n'autorise pas d'opération, levez une instance de InvalidOperationException ou un objet basé sur une dérivation de cette classe. Voici un exemple d'une méthode qui lève un objet InvalidOperationException :
class ProgramLog { System.IO.FileStream logFile = null; void OpenLog(System.IO.FileInfo fileName, System.IO.FileMode mode) {} void WriteLog() { if (!this.logFile.CanWrite) { throw new System.InvalidOperationException("Logfile cannot be read-only"); } // Else write data to the log and return. } }Lorsqu'un argument de méthode provoque une exception.
Dans ce cas, l'exception d'origine doit être interceptée et une instance ArgumentException doit être créée. L'exception d'origine doit être passée au constructeur de ArgumentException en tant que paramètre InnerException :
static int GetValueFromArray(int[] array, int index) { try { return array[index]; } catch (System.IndexOutOfRangeException ex) { System.ArgumentException argEx = new System.ArgumentException("Index is out of range", "index", ex); throw argEx; } }
Les exceptions contiennent une propriété nommée StackTrace. Cette chaîne contient le nom des méthodes sur la pile des appels actuelle, avec le nom de fichier et le numéro de ligne où l'exception a été levée pour chaque méthode. Un objet StackTrace étant créé automatiquement par le Common Language Runtime (CLR) à partir du point de l'instruction throw, les exceptions doivent être levées à partir du point où la trace de la pile doit commencer.
Toutes les exceptions contiennent une propriété nommée Message. Cette chaîne doit être configurée pour expliquer la raison de l'exception. Notez que les informations sensibles du point de vue de la sécurité ne doivent pas être placées dans le texte du message. Outre Message, ArgumentException contient une propriété nommée ParamName qui doit être définie au nom de l'argument qui a provoqué la levée de l'exception. Dans le cas d'un accesseur Set de propriété, ParamName doit avoir la valeur value.
Les membres de méthodes publiques et protégées doivent lever des exceptions dès qu'ils ne peuvent pas réaliser leur fonction prévue. La classe d'exception qui est levée doit être l'exception la plus spécifique disponible répondant aux conditions d'erreur. Ces exceptions doivent être documentées dans le cadre de la fonctionnalité de la classe ; les classes dérivées ou les mises à jour de la classe d'origine doivent conserver le même comportement afin d'assurer la compatibilité descendante.
Pratiques à éviter lors de la levée des exceptions
La liste suivante identifie les pratiques à éviter lors de la levée des exceptions :
Les exceptions ne doivent pas être utilisées pour modifier le flux d'un programme dans le cadre d'une exécution ordinaire. Les exceptions doivent être utilisées uniquement pour signaler et gérer les conditions d'erreur.
Les exceptions ne doivent pas être retournées en tant que valeur de retour ou paramètre au lieu d'être levées.
Ne levez pas intentionnellement Exception, SystemException, NullReferenceException ou IndexOutOfRangeException à partir de votre propre code source.
Ne créez pas d'exceptions qui peuvent être levées en mode Debug mais pas en mode Release. Pour identifier des erreurs d'exécution pendant la phase de développement, utilisez plutôt Debug Assert.
Définition de classes d'exceptions
Les programmes peuvent lever une classe d'exception prédéfinie dans l'espace de noms System (sauf dans les endroits précédemment notés) ou créer leurs propres classes d'exception en les dérivant de Exception. Les classes dérivées doivent définir au moins quatre constructeurs : un constructeur par défaut, un qui définit la propriété du message et un qui définit les deux propriétés Message et InnerException. Le quatrième constructeur est utilisé pour sérialiser l'exception. Les nouvelles classes d'exception doivent être sérialisables. Par exemple :
[Serializable()]
public class InvalidDepartmentException : System.Exception
{
public InvalidDepartmentException() : base() { }
public InvalidDepartmentException(string message) : base(message) { }
public InvalidDepartmentException(string message, System.Exception inner) : base(message, inner) { }
// A constructor is needed for serialization when an
// exception propagates from a remoting server to the client.
protected InvalidDepartmentException(System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context) { }
}
Les nouvelles propriétés doivent uniquement être ajoutées à la classe d'exceptions lorsque les données qu'elles fournissent sont utiles à la résolution de l'exception. Si les nouvelles propriétés sont ajoutées à la classe d'exceptions dérivée, ToString() doit être substitué pour retourner les informations ajoutées.
Spécification du langage C#
Pour plus d'informations, voir la Spécification du langage C#. La spécification du langage est la source de référence pour la syntaxe C# et son utilisation.
Voir aussi
Référence
Exceptions et gestion des exceptions (Guide de programmation C#)
Gestion des exceptions (Guide de programmation C#)