Try catch ב-C#: טיפול בחריגות עם catch, when ו-finally

כשמשהו משתבש בזמן ריצה (קובץ חסר, טקסט שאינו מספר, מפתח שלא נמצא במילון), .NET זורקת חריגה: אובייקט שמתאר את השגיאה. החריגה עולה במחסנית הקריאות עד שבלוק catch מטפל בה. אם שום דבר לא מטפל, התוכנית נעצרת ומדפיסה את השגיאה.

try catch בסיסי

עטפו את הקוד שעלול להיכשל ב-try, וטפלו בכישלון ב-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");
    }
}

פלט:

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

כש-int.Parse("forty-two") זורקת, ה-Console.WriteLine שאחריה בבלוק ה-try מדולג, בלוק ה-catch (FormatException) רץ, והלולאה ממשיכה. אפשר להשמיט את המשתנה (catch (FormatException)) כשלא צריכים את אובייקט החריגה.

למקרה הספציפי הזה יש כלי טוב יותר: int.TryParse(input, out int n) מחזירה false במקום לזרוק. חריגות מיועדות למצבים שהקוד לא מצפה להם; קלט שלעיתים קרובות לא תקין הוא צפוי, אז בדקו אותו במקום לתפוס.

איך חריגה עוברת

חריגה שנזרקת עמוק בתוך שרשרת קריאות פורמת כל מתודה עד שהיא מוצאת מטפל מתאים. הקוד שאחרי הזריקה בכל אחת מהמתודות האלה לא רץ.

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

פלט:

OrderTotal finished
5.00
Caught KeyNotFoundException in Main

ל-PriceOf ול-OrderTotal אין catch, כך שהחריגה עוברת דרכן ישר ל-Main. שימו מטפל ברמה שיודעת מה לעשות עם הכישלון, ולרוב זו לא הרמה שבה הוא קרה.

תפיסת חריגות ספציפיות, בסדר הנכון

פסוקית catch מטפלת בטיפוס שלה ובכל טיפוס שיורש ממנו. כשיש כמה פסוקיות, הראשונה שמתאימה מנצחת, אז סדרו אותן מהספציפית ביותר לכללית ביותר:

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
    }
}

פלט:

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

הקריאה האחרונה זורקת OverflowException, שאף אחת מהפסוקיות הספציפיות לא מטפלת בה, ולכן ה-catch (Exception e) הכללית מטפלת. הצבת catch (Exception) ראשונה הייתה הופכת את הפסוקיות שאחריה לבלתי ניתנות להשגה, והקומפיילר דוחה את זה עם שגיאה CS0160.

מסנני חריגות עם when

C# 6 הוסיפה את when: תנאי שמחליט אם פסוקית catch חלה. אם הוא false, סביבת הריצה ממשיכה לחפש מטפל אחר כאילו הפסוקית לא קיימת.

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

פלט:

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

מסננים מאפשרים להסתעף לפי נתונים שבתוך החריגה בלי לתפוס ולזרוק מחדש. הם גם הדרך הנקייה לטפל בשני טיפוסים לא קשורים באופן זהה, כמו שהפסוקית השלישית עושה. מסנן רץ לפני שהמחסנית נפרמת, כך ש-debugger או crash dump עדיין מציגים את המצב המקורי כששום מסנן לא מתאים.

finally: קוד שתמיד רץ

בלוק finally רץ כשהשליטה עוזבת את ה-try, בין אם הוא הסתיים, חזר מוקדם או זרק. זה המקום לקוד הניקוי. (הסתייגות אחת: אם שום דבר בשום מקום לא תופס את החריגה, התהליך יכול להסתיים בלי להריץ אותו.)

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

פלט:

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

בכל המקרים "Close connection" מודפס לפני שהתוצאה של המתודה מגיעה ל-Main: ה-finally רץ אחרי שערך ה-return חושב אבל לפני שהמתודה באמת חוזרת. ל-try יכול להיות finally בלי catch בכלל, וכך הוא מנקה ועדיין נותן לחריגה להמשיך לקורא.

לאובייקטים שמממשים IDisposable (קבצים, זרמים, חיבורים), פקודת using כותבת את ה-try/finally הזה בשבילכם.

זריקה מחדש: throw; מול throw e;

לפעמים בלוק catch רושם משהו ללוג ואז נותן לחריגה להמשיך. האופן שבו זורקים מחדש קובע אם ה-stack trace שורד:

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

פלט:

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

throw e; מתייחסת לחריגה כאילו נזרקה מחדש מבלוק ה-catch, כך שהמסגרות שמתחתיו, כולל המתודה שבה השגיאה קרתה, נעלמות מה-trace. זרקו מחדש תמיד עם throw; חשוף. (המאפיין NoInlining נמצא שם רק כי ה-JIT עשוי למזג מתודה קטנה כל כך לתוך הקורא שלה, וזה היה מסתיר אותה משני ה-traces.)

כדי להוסיף הקשר במקום זאת, עטפו את החריגה בחריגה חדשה והעבירו את המקורית כחריגה הפנימית: throw new ConfigException("Could not start the app", e);. לחריגה הפנימית נשמר ה-stack trace שלה, ו-loggers מדפיסים את השרשרת. כתיבת טיפוסי חריגה משלכם מכוסה ב-זריקת חריגות.

אובייקט ה-Exception

כל חריגה יורשת מ-System.Exception. האיברים שמשתמשים בהם הכי הרבה:

רשמו ללוג את e.ToString() ולא את e.Message כשרוצים לאבחן כישלון מאוחר יותר: ההודעה לבדה כמעט אף פעם לא אומרת איפה הבעיה הייתה. אל תציגו את e.ToString() למשתמשי קצה.

טיפוסי חריגות נפוצים

NullReferenceException, IndexOutOfRangeException ו-InvalidCastException מעידות כמעט תמיד על באג. תקנו את הקוד במקום לתפוס אותן.

לא לבלוע חריגות

catch ריק מסתיר כל שגיאה, כולל כאלה שלא ציפיתם להן:

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

התוכנית ממשיכה לרוץ כאילו השמירה הצליחה, והסיבה האמיתית אובדת. הנחיות ששומרות על טיפול כן בחריגות:

• תפסו רק את מה שאתם יכולים לטפל בו, ברמה שיכולה לטפל בו.
• אם אתם תופסים כדי לרשום ללוג, זרקו מחדש עם throw; אלא אם התוכנית באמת יכולה להמשיך.
• תפסו Exception רק בקצה החיצוני: Main, מטפל בקשות, לולאת worker.
• העדיפו TryParse, TryGetValue ובדיקות null על פני חריגות במקרים צפויים. זריקה איטית בהשוואה לבדיקה, בעוד שבלוק try שלא זורק כלום כמעט לא עולה דבר.

טעויות נפוצות

• catch (Exception) ראשון. הפסוקיות שאחריו הופכות לבלתי ניתנות להשגה (CS0160).
• throw e; לזריקה מחדש. זה מוחק את ה-stack trace המקורי; השתמשו ב-throw;.
• בלוקי catch ריקים. שגיאות נעלמות; לפחות רשמו ללוג וזרקו מחדש.
• שימוש בחריגות לבקרת זרימה. בדקו קלט עם TryParse במקום לתפוס FormatException.
• הצגת e.Message של חריגת framework למשתמשים. הניסוח משתנה בין גרסאות .NET ונכתב עבור מפתחים.