Levée d'exceptions

Article
08/21/2008

Mise à jour : novembre 2007

Des exceptions sont levées lorsqu'un membre n'arrive pas à effectuer ce pourquoi il a été conçu. On parle dans ce cas d'échec 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 instructions 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.

É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);
            }
        }
    }
}

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

É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)

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

Cette instruction 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.

Pour plus d'informations sur les instructions de conception, consultez le livre « Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries » de Krzysztof Cwalina et Brad Abrams, publié 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

Partager via