try catch en C# : gérer les exceptions avec catch, when et finally

Quand quelque chose tourne mal à l'exécution (un fichier manque, un texte n'est pas un nombre, une clé n'est pas dans un dictionnaire), .NET lève une exception : un objet qui décrit l'erreur. L'exception remonte la pile d'appels jusqu'à ce qu'un bloc catch la traite. Si rien ne la traite, le programme s'arrête et affiche l'erreur.

Un try catch simple

Enveloppez le code qui peut échouer dans try, et traitez l'échec dans catch :

using System;

class Program
{
    static void Main()
    {
        string[] inputs = { "42", "forty-two", "7" };

        foreach (string input in inputs)
        {
            try
            {
                int n = int.Parse(input);
                Console.WriteLine(input + " doubled is " + (n * 2));
            }
            catch (FormatException)
            {
                Console.WriteLine("'" + input + "' is not a number");
            }
        }
        Console.WriteLine("Still running");
    }
}

Sortie :

42 doubled is 84
'forty-two' is not a number
7 doubled is 14
Still running

Quand int.Parse("forty-two") lève une exception, le Console.WriteLine qui le suit dans le bloc try est sauté, le bloc catch (FormatException) s'exécute, et la boucle continue. Vous pouvez omettre la variable (catch (FormatException)) quand vous n'avez pas besoin de l'objet exception.

Ce cas précis a un meilleur outil : int.TryParse(input, out int n) renvoie false au lieu de lever une exception. Les exceptions servent aux situations que le code n'attend pas ; une saisie souvent invalide est attendue, donc vérifiez-la au lieu d'intercepter.

Comment une exception remonte

Une exception levée au fond d'une chaîne d'appels déroule chaque méthode jusqu'à trouver un gestionnaire correspondant. Le code qui suit le point de levée dans chacune de ces méthodes ne s'exécute pas.

using System;
using System.Collections.Generic;

class Program
{
    static Dictionary<string, decimal> prices = new Dictionary<string, decimal>
    {
        ["tea"] = 2.50m,
    };

    static decimal PriceOf(string item)
    {
        return prices[item];                         // throws for a missing item
    }

    static decimal OrderTotal(string item, int qty)
    {
        decimal total = PriceOf(item) * qty;
        Console.WriteLine("OrderTotal finished");    // skipped when PriceOf throws
        return total;
    }

    static void Main()
    {
        try
        {
            Console.WriteLine(OrderTotal("tea", 2));
            Console.WriteLine(OrderTotal("cake", 1));
            Console.WriteLine("not reached");
        }
        catch (KeyNotFoundException e)
        {
            Console.WriteLine("Caught " + e.GetType().Name + " in Main");
        }
    }
}

Sortie :

OrderTotal finished
5.00
Caught KeyNotFoundException in Main

PriceOf et OrderTotal n'ont pas de catch, donc l'exception les traverse directement jusqu'à Main. Placez un gestionnaire au niveau qui sait quoi faire de l'échec, ce qui n'est souvent pas là où il s'est produit.

Intercepter des exceptions précises, dans le bon ordre

Une clause catch traite son type et tous les types qui en dérivent. Quand il y a plusieurs clauses, la première qui correspond l'emporte, donc classez-les du plus spécifique au plus général :

using System;

class Program
{
    static void Divide(string a, string b)
    {
        try
        {
            int x = int.Parse(a);
            int y = int.Parse(b);
            Console.WriteLine(a + " / " + b + " = " + (x / y));
        }
        catch (DivideByZeroException)
        {
            Console.WriteLine("Cannot divide by zero");
        }
        catch (FormatException)
        {
            Console.WriteLine("Both values must be whole numbers");
        }
        catch (Exception e)
        {
            Console.WriteLine("Unexpected: " + e.GetType().Name);
        }
    }

    static void Main()
    {
        Divide("10", "2");
        Divide("10", "0");
        Divide("ten", "2");
        Divide("99999999999", "1"); // too large for int
    }
}

Sortie :

10 / 2 = 5
Cannot divide by zero
Both values must be whole numbers
Unexpected: OverflowException

Le dernier appel lève OverflowException, qu'aucune clause spécifique ne traite, donc c'est le catch (Exception e) général qui s'en charge. Placer catch (Exception) en premier rendrait les clauses suivantes inaccessibles, et le compilateur le refuse avec l'erreur CS0160.

Filtres d'exception avec when

C# 6 a ajouté when : une condition qui décide si une clause catch s'applique. Si elle vaut false, le runtime continue de chercher un autre gestionnaire comme si la clause n'existait pas.

using System;

class ApiException : Exception
{
    public int StatusCode { get; }
    public ApiException(int statusCode) : base("HTTP " + statusCode)
    {
        StatusCode = statusCode;
    }
}

class Program
{
    static void Call(int status)
    {
        try
        {
            throw new ApiException(status);
        }
        catch (ApiException e) when (e.StatusCode == 404)
        {
            Console.WriteLine("Not found: show an empty page");
        }
        catch (ApiException e) when (e.StatusCode >= 500)
        {
            Console.WriteLine("Server error " + e.StatusCode + ": retry later");
        }
        catch (Exception e) when (e is ArgumentException || e is FormatException)
        {
            Console.WriteLine("Bad input");
        }
    }

    static void Main()
    {
        Call(404);
        Call(503);
        try
        {
            Call(401); // no clause matches: it propagates
        }
        catch (ApiException e)
        {
            Console.WriteLine("Unhandled by Call: " + e.Message);
        }
    }
}

Sortie :

Not found: show an empty page
Server error 503: retry later
Unhandled by Call: HTTP 401

Les filtres permettent de choisir une branche selon des données contenues dans l'exception sans intercepter puis relancer. Ils sont aussi la façon propre de traiter de manière identique deux types sans rapport, comme le fait la troisième clause. Un filtre s'exécute avant le déroulement de la pile, donc un débogueur ou un vidage mémoire après plantage montre encore l'état d'origine quand aucun filtre ne correspond.

finally : du code qui s'exécute toujours

Un bloc finally s'exécute quand le contrôle quitte le try, qu'il se soit terminé, soit revenu plus tôt ou ait levé une exception. C'est là que va le nettoyage. (Une réserve : si rien n'intercepte l'exception nulle part, le processus peut se terminer sans l'exécuter.)

using System;

class Program
{
    static string Process(int step)
    {
        Console.WriteLine("Open connection");
        try
        {
            if (step == 1) return "returned early";
            if (step == 2) throw new InvalidOperationException();
            return "finished";
        }
        catch (InvalidOperationException)
        {
            return "handled error";
        }
        finally
        {
            Console.WriteLine("Close connection");
        }
    }

    static void Main()
    {
        Console.WriteLine(Process(0));
        Console.WriteLine(Process(1));
        Console.WriteLine(Process(2));
    }
}

Sortie :

Open connection
Close connection
finished
Open connection
Close connection
returned early
Open connection
Close connection
handled error

Dans tous les cas, « Close connection » s'affiche avant que le résultat de la méthode n'atteigne Main : le finally s'exécute après le calcul de la valeur du return, mais avant que la méthode ne revienne réellement. Un try peut avoir un finally sans aucun catch, ce qui nettoie tout en laissant l'exception continuer vers l'appelant.

Pour les objets qui implémentent IDisposable (fichiers, flux, connexions), l'instruction using écrit ce try/finally pour vous.

Relancer : throw; ou throw e;

Parfois, un bloc catch journalise ou enregistre quelque chose puis laisse l'exception continuer. La façon de relancer détermine si la trace de pile survit :

using System;
using System.Runtime.CompilerServices;

class Program
{
    // NoInlining keeps this small method as its own frame in the stack trace.
    [MethodImpl(MethodImplOptions.NoInlining)]
    static void LoadConfig()
    {
        throw new InvalidOperationException("config file missing");
    }

    static void RethrowKeep()
    {
        try { LoadConfig(); }
        catch (InvalidOperationException) { throw; }      // original trace
    }

    static void RethrowReset()
    {
        try { LoadConfig(); }
        catch (InvalidOperationException e) { throw e; }  // trace restarts here
    }

    static void Main()
    {
        try { RethrowKeep(); }
        catch (Exception e)
        {
            Console.WriteLine("throw;   trace mentions LoadConfig: " + e.StackTrace.Contains("LoadConfig"));
        }

        try { RethrowReset(); }
        catch (Exception e)
        {
            Console.WriteLine("throw e; trace mentions LoadConfig: " + e.StackTrace.Contains("LoadConfig"));
        }
    }
}

Sortie :

throw;   trace mentions LoadConfig: True
throw e; trace mentions LoadConfig: False

throw e; traite l'exception comme nouvellement levée depuis le bloc catch, donc les cadres situés en dessous, y compris la méthode où l'erreur s'est produite, disparaissent de la trace. Relancez toujours avec un simple throw;. (L'attribut NoInlining n'est là que parce que le JIT pourrait fusionner une méthode aussi petite avec son appelant, ce qui la cacherait des deux traces.)

Pour ajouter du contexte, enveloppez plutôt l'exception dans une nouvelle et passez l'originale comme exception interne : throw new ConfigException("Could not start the app", e);. L'exception interne garde sa propre trace de pile, et les outils de journalisation affichent la chaîne. Écrire vos propres types d'exception est présenté dans lever des exceptions.

L'objet Exception

Toute exception dérive de System.Exception. Les membres que vous utiliserez le plus :

Journalisez e.ToString() plutôt que e.Message quand vous voulez diagnostiquer un échec plus tard : le message seul dit rarement où était le problème. Ne montrez pas e.ToString() aux utilisateurs finaux.

Types d'exception courants

NullReferenceException, IndexOutOfRangeException et InvalidCastException signalent presque toujours un bug. Corrigez le code plutôt que de les intercepter.

Ne pas avaler les exceptions

Un catch vide cache toutes les erreurs, y compris celles que vous n'aviez pas prévues :

try
{
    SaveOrder(order);
}
catch (Exception)
{
    // nothing: the order silently was not saved
}

Le programme continue comme si l'enregistrement avait fonctionné, et la vraie cause est perdue. Des règles qui gardent la gestion des exceptions honnête :

• N'interceptez que ce que vous pouvez traiter, au niveau qui peut le traiter.
• Si vous interceptez pour journaliser, relancez avec throw;, sauf si le programme peut vraiment continuer.
• N'interceptez Exception qu'à la limite extérieure : Main, un gestionnaire de requêtes, une boucle de travail.
• Préférez TryParse, TryGetValue et les tests de null aux exceptions pour les cas attendus. Lever une exception est lent comparé à un test, alors qu'un bloc try qui ne lève rien ne coûte presque rien.

Erreurs courantes

• catch (Exception) en premier. Les clauses suivantes deviennent inaccessibles (CS0160).
• throw e; pour relancer. Cela efface la trace de pile d'origine ; utilisez throw;.
• Des blocs catch vides. Les erreurs disparaissent ; au minimum, journalisez et relancez.
• Utiliser les exceptions pour le flux de contrôle. Validez la saisie avec TryParse au lieu d'intercepter FormatException.
• Montrer aux utilisateurs le e.Message d'une exception du framework. Sa formulation change d'une version de .NET à l'autre et elle est écrite pour les développeurs.