Levée d'exceptions

Les exceptions sont levées lorsqu'un membre ne peut pas faire avec succès ce qu'il est conçu pour faire. Cela est appelé erreur d'exécution. Si, par exemple, la méthode Connect ne peut pas se connecter au point de terminaison distant spécifié, cette tentative est considérée comme un échec d'exécution et une exception est levée.

Le respect des règles suivantes garantit que les exceptions sont levées dans les circonstances appropriées.

Ne retournez pas de codes d'erreur. Les exceptions constituent le principal moyen de signaler la présence d'erreurs dans les infrastructures.

Instructions de conception pour les exceptions présente les nombreux avantages offerts par l'utilisation des exceptions.

Signalez les échecs d'exécution en levant des exceptions. Si un membre ne parvient pas à effectuer ce pourquoi il a été conçu, ce doit être considéré comme un échec d'exécution et une exception doit être levée.

Envisagez de mettre un terme au processus en appelant System.Environment.FailFast (System.String) (une fonctionnalité du .NET Framework version 2.0) au lieu de lever une exception, si votre code rencontre une situation dans laquelle la poursuite de l'exécution présente un risque.

Évitez dans la mesure du possible d'utiliser des exceptions pour le flux normal de contrôle. À l'exception des défaillances système et des opérations présentant des conditions de concurrence critique potentielles, les concepteurs d'infrastructures doivent concevoir les API de telle sorte que les utilisateurs puissent écrire du code qui ne lève pas d'exceptions. Par exemple, vous avez la possibilité de vérifier des conditions préalables avant d'appeler un membre afin que les utilisateurs puissent écrire du code qui ne lève pas d'exceptions.

L'exemple de code suivant illustre un test visant à prévenir la levée d'exceptions lorsqu'une chaîne de message est null (Nothing en Visual Basic).

Public Class Doer

    ' Method that can potential throw exceptions often.
    Public Shared Sub ProcessMessage(ByVal message As String)
        If (message = Nothing) Then
            Throw New ArgumentNullException("message")
        End If
    End Sub

    ' Other methods...
End Class

Public Class Tester

    Public Shared Sub TesterDoer(ByVal messages As ICollection(Of String))
        For Each message As String In messages
            ' Test to ensure that the call 
            ' won't cause the exception.
            If (Not (message) Is Nothing) Then
                Doer.ProcessMessage(message)
            End If
        Next
    End Sub
End Class

public class Doer
{
    // Method that can potential throw exceptions often.
    public static void ProcessMessage(string message)
    {
        if (message == null)
        {
            throw new ArgumentNullException("message");
        }
    }
    // Other methods...
}

public class Tester
{
    public static void TesterDoer(ICollection<string> messages)
    {
        foreach (string message in messages)
        {
            // Test to ensure that the call
            // won't cause the exception.
            if (message != null)
            {
                Doer.ProcessMessage(message);
            }
        }
    }
}

public ref class Doer
{
public:
    // Method that can potential throw exceptions often.
    static void ProcessMessage(String^ message)
    {
        if (message == nullptr)
        {
            throw gcnew ArgumentNullException("message");
       }
    }
    // Other methods...
};

public ref class Tester
{
public:
    static void TesterDoer(ICollection<String^>^ messages)
    {
        for each (String^ message in messages)
        {
            // Test to ensure that the call
            // won't cause the exception.
            if (message != nullptr)
            {
                Doer::ProcessMessage(message);
            }
        }
    }
};

Pour plus d'informations sur les modèles de design permettant de limiter le nombre d'exceptions levées, consultez Exceptions et performances.

Étudiez les répercussions de la levée d'exceptions sur les performances.

Documentez toutes les exceptions levées par des membres pouvant être appelés publiquement, en raison d'une violation du contrat du membre (plutôt qu'une défaillance système) et traitez-les dans le cadre de votre contrat. Les exceptions qui font partie du contrat ne doivent pas changer d'une version à l'autre.

Évitez d'avoir des membres publics qui peuvent lever, ou non, des exceptions en fonction d'une option quelconque.

Par exemple, ne définissez pas les membres suivants :

Private Function ParseUri(ByVal uriValue As String, ByVal throwOnError As Boolean) As Uri

Uri ParseUri(string uriValue, bool throwOnError)

Uri^ ParseUri(String^ uriValue, bool throwOnError)

Évitez les membres publics qui retournent des exceptions comme valeur de retour ou comme paramètre out.

Cette règle concerne les membres visibles publiquement. L'utilisation d'une méthode d'assistance privée pour construire et initialiser des exceptions est admise.

Envisagez d'utiliser des méthodes de générateur d'exceptions. Il arrive fréquemment que la même exception soit levée dans des emplacements différents. Pour éviter un excès de code, utilisez des méthodes d'assistance qui créent des exceptions et initialisent leurs propriétés.

La méthode d'assistance ne doit pas lever l'exception sans quoi la trace de la pile ne reflétera pas correctement la pile des appels à l'origine de l'exception.

Ne levez pas d'exceptions à partir de blocs de filtre d'exceptions. Lorsqu'un filtre d'exceptions lève une exception, celle-ci est interceptée par le Common Language Runtime, et le filtre retourne la valeur false. Il est impossible de distinguer ce comportement de celui où le filtre exécute et retourne explicitement la valeur false. Par conséquent, le code est très difficile à déboguer.

Certains langages, tels que C#, ne prennent pas en charge les filtres d'exceptions.

Évitez de lever explicitement des exceptions à partir de blocs finally. Les exceptions levées implicitement à la suite d'appels de méthodes sont admises.

Portions Copyright 2005 Microsoft Corporation. Tous droits réservés.

Portions Copyright Addison-Wesley Corporation. Tous droits réservés.

Pour plus d'informations sur les règles de conception, consultez « règles de conception d'infrastructure : Conventions idiomes et modèles carnet de bibliothèques réutilisables framework » Krzysztof Cwalina et Brad Abrams, publiés par Addison-Wesley, 2005.

Voir aussi

Concepts

Choix du type correct d'exception à lever

Autres ressources

Instructions de conception pour le développement de bibliothèques de classes

Instructions de conception pour les exceptions