مدیریت خطاها (Exception Handling) در C#: از تئوری تا عمل

توسعه نرم‌افزار در دنیای پیچیده امروز، بدون یک استراتژی قدرتمند برای مواجهه با اتفاقات پیش‌بینی‌نشده، همچون قدم گذاشتن در میدان مین بدون نقشه‌برداری است. خطاها بخش جدایی‌ناپذیری از هر سیستم نرم‌افزاری هستند و نحوه مدیریت آن‌ها، تفاوت بین یک برنامه پایدار و قابل اعتماد با سیستمی مستعد شکست را رقم می‌زند. در اکوسیستم .NET و به‌ویژه زبان C#، مفهوم مدیریت استثناها (Exception Handling) ابزاری قدرتمند و استاندارد برای این منظور فراهم آورده است. این رویکرد به توسعه‌دهندگان امکان می‌دهد تا کدی منظم و خوانا برای مدیریت شرایط خطا بنویسند، بدون آنکه منطق اصلی برنامه در میان بررسی‌های بی‌پایان شرایط نامتعارف گم شود.

در این مقاله جامع و تخصصی، قصد داریم به طور عمیق به مفهوم مدیریت استثناها در C# بپردازیم. از مبانی تئوریک و دلایل ضرورت آن گرفته تا پیاده‌سازی‌های عملی، بهترین رویه‌ها، ملاحظات عملکردی، و ابزارهای پیشرفته برای پایش و ثبت خطاها. هدف این است که در پایان، شما نه تنها با سازوکارهای فنی try-catch-finally آشنا باشید، بلکه بتوانید یک استراتژی جامع و کارآمد برای مدیریت خطاها در پروژه‌های بزرگ و پیچیده خود تدوین و پیاده‌سازی کنید.

این سفر از تئوری به عمل، به شما کمک می‌کند تا برنامه‌هایی robust‌تر، resilient‌تر و با تجربه کاربری بهتری ایجاد کنید، و از تبدیل شدن خطاهای پیش‌بینی‌نشده به کابوسی برای کاربران و توسعه‌دهندگان جلوگیری نمایید.

مقدمه: چرا مدیریت خطا ضروری است؟

برای درک اهمیت مدیریت استثناها، ابتدا باید تعریفی روشن از “خطا” در زمینه نرم‌افزار داشته باشیم. در برنامه‌نویسی، خطاها معمولاً به سه دسته کلی تقسیم می‌شوند:

1. خطاهای کامپایل (Compile-time Errors): این خطاها توسط کامپایلر تشخیص داده می‌شوند و معمولاً ناشی از اشتباهات گرامری یا ساختاری در کد هستند (Syntax Errors). تا زمانی که این خطاها برطرف نشوند، برنامه کامپایل و اجرا نخواهد شد.
2. خطاهای منطقی (Logical Errors): این خطاها در زمان اجرا رخ می‌دهند اما برنامه متوقف نمی‌شود. به عبارت دیگر، برنامه کاری را انجام می‌دهد که از آن انتظار ندارید. برای مثال، یک الگوریتم اشتباه که منجر به محاسبه غلط می‌شود. تشخیص و رفع این خطاها معمولاً دشوارتر است و نیاز به دیباگینگ دقیق دارد.
3. خطاهای زمان اجرا (Runtime Errors) یا استثناها (Exceptions): این خطاها در زمان اجرای برنامه و به دلیل وقوع شرایط غیرعادی رخ می‌دهند که برنامه نتواند به صورت عادی ادامه دهد. برای مثال، تلاش برای تقسیم بر صفر، دسترسی به فایلی که وجود ندارد، یا اتصال به پایگاه داده‌ای که در دسترس نیست. این نوع خطاها در صورت عدم مدیریت صحیح، منجر به کراش شدن (Crash) برنامه و خروج ناگهانی آن می‌شوند.

موضوع اصلی این مقاله، دسته سوم یعنی استثناها است. در گذشته، بسیاری از زبان‌ها برای مدیریت این شرایط، به کدهای بازگشتی (Error Codes) یا بررسی‌های شرطی بی‌پایان (if-else) تکیه می‌کردند. این رویکردها اغلب منجر به کدی شلوغ، غیرقابل خواندن و مستعد خطا می‌شدند، چرا که منطق اصلی برنامه در میان بررسی‌های خطای متعدد گم می‌شد.

رویکرد مدیریت استثناها، یک مکانیزم ساختاریافته‌تر و تمیزتر برای مواجهه با این شرایط غیرعادی فراهم می‌کند. به جای اینکه هر متد مسئول بررسی موفقیت یا شکست عملیات‌های زیرین خود باشد، می‌تواند در صورت بروز مشکل، یک “استثنا” را “پرتاب” (throw) کند. این استثنا سپس توسط یک “بلوک مدیریت استثنا” در بالاتر دست “گرفته” (catch) می‌شود. این جداسازی concerns (تفکیک منطق تجاری از منطق مدیریت خطا) مزایای متعددی دارد:

• خوانایی و نگهداری بهتر کد: منطق اصلی برنامه بدون درهم‌ریختگی با کدهای مدیریت خطا، شفاف‌تر می‌شود.
• افزایش پایداری: با گرفتن استثناها، می‌توانید از کراش شدن ناگهانی برنامه جلوگیری کرده و به آن اجازه دهید به صورت graceful بازیابی شود یا حداقل اطلاعات کافی برای عیب‌یابی را ثبت کند.
• تجربه کاربری بهبود یافته: به جای پیغام‌های خطای مبهم یا کراش برنامه، می‌توانید پیغام‌های خطای معنی‌دار و راهنمای کاربرپسند ارائه دهید.
• تمرکز بر Business Logic: توسعه‌دهندگان می‌توانند بیشتر بر روی پیاده‌سازی منطق تجاری تمرکز کنند و مدیریت خطاها را به مکانیسم‌های مرکزی بسپارند.

در C#، مدیریت استثناها یک بخش جدایی‌ناپذیر از طراحی زبان و چارچوب .NET است. کلاس System.Exception ریشه تمام استثناها است و چارچوب .NET انواع از پیش تعریف شده‌ای از استثناها را برای سناریوهای رایج فراهم می‌کند، مانند FileNotFoundException، NullReferenceException، ArgumentException و غیره.

مبانی مدیریت خطا در C#: Try, Catch, Finally

در C#، سه کلمه کلیدی اصلی برای مدیریت استثناها وجود دارد: try، catch و finally. این کلمات کلیدی، بلوک‌هایی از کد را تعریف می‌کنند که به برنامه اجازه می‌دهند تا به طور ایمن با شرایط خطای زمان اجرا برخورد کند.

بلوک try

بلوک try جایی است که شما کدی را قرار می‌دهید که احتمال دارد یک استثنا را پرتاب کند. این بلوک به CLR (Common Language Runtime) سیگنال می‌دهد که بر اجرای کد درون آن نظارت داشته باشد. اگر در حین اجرای کد درون بلوک try، استثنایی پرتاب شود، CLR جستجو برای یک بلوک catch مناسب را آغاز می‌کند.

try
{
    // کدی که ممکن است استثنایی را پرتاب کند
    int numerator = 10;
    int denominator = 0;
    int result = numerator / denominator; // این خط منجر به DivideByZeroException خواهد شد
    Console.WriteLine($"Result: {result}");
}

بلوک catch

بلوک catch برای گرفتن و مدیریت استثناهایی استفاده می‌شود که در بلوک try مربوطه پرتاب شده‌اند. شما می‌توانید چندین بلوک catch برای گرفتن انواع مختلف استثناها داشته باشید. هر بلوک catch می‌تواند یک نوع استثنای خاص را مشخص کند، یا می‌تواند به طور کلی System.Exception را بگیرد که والد همه استثناها است.

try
{
    int numerator = 10;
    int denominator = 0;
    int result = numerator / denominator;
    Console.WriteLine($"Result: {result}");
}
catch (DivideByZeroException ex)
{
    // این بلوک زمانی اجرا می‌شود که یک DivideByZeroException پرتاب شود
    Console.WriteLine("خطا: تلاش برای تقسیم بر صفر!");
    Console.WriteLine($"جزئیات خطا: {ex.Message}");
    // می‌توانید لاگ‌نویسی کنید، به کاربر اطلاع دهید یا عملیات بازیابی را انجام دهید
}
catch (Exception ex)
{
    // این بلوک هر نوع استثنای دیگری را که در بالا گرفته نشده باشد، می‌گیرد
    Console.WriteLine("خطای ناشناخته‌ای رخ داده است.");
    Console.WriteLine($"جزئیات خطا: {ex.Message}");
}

نکته مهم در مورد بلوک‌های catch این است که ترتیب آن‌ها اهمیت دارد. بلوک‌های catch با استثناهای خاص‌تر (specific) باید قبل از بلوک‌های catch با استثناهای عمومی‌تر (general) قرار گیرند. اگر catch (Exception ex) را قبل از catch (DivideByZeroException ex) قرار دهید، استثنای خاص‌تر هرگز گرفته نخواهد شد.

بلوک finally

بلوک finally کدی را شامل می‌شود که همیشه اجرا می‌شود، صرف نظر از اینکه استثنایی در بلوک try پرتاب شده باشد یا خیر، و صرف نظر از اینکه استثنا گرفته شده باشد یا خیر. این بلوک برای پاکسازی منابع (مانند بستن فایل‌ها، اتصالات دیتابیس، یا آزادسازی حافظه) بسیار مفید است، زیرا اطمینان می‌دهد که منابع حتی در صورت بروز خطا نیز به درستی آزاد می‌شوند.

System.IO.StreamReader? reader = null;
try
{
    reader = new System.IO.StreamReader("nonexistent_file.txt");
    string line = reader.ReadLine();
    Console.WriteLine(line);
}
catch (System.IO.FileNotFoundException ex)
{
    Console.WriteLine($"خطا: فایل پیدا نشد! {ex.Message}");
}
catch (Exception ex)
{
    Console.WriteLine($"خطای کلی: {ex.Message}");
}
finally
{
    // این بلوک همیشه اجرا می‌شود، چه فایل پیدا شود چه نه، و چه خطای دیگری رخ دهد.
    // اطمینان از بسته شدن خواننده فایل
    if (reader != null)
    {
        reader.Close();
        Console.WriteLine("منبع فایل بسته شد.");
    }
}

بلوک finally تضمین می‌کند که عملیات پاکسازی انجام می‌شود، حتی اگر متدی که استثنا را پرتاب کرده است، در مسیر پرتاب استثنای خود، از بلوک try خارج شود. این ویژگی برای جلوگیری از نشت منابع (Resource Leaks) حیاتی است.

استفاده از using برای منابع قابل Dispose:

برای منابعی که اینترفیس IDisposable را پیاده‌سازی می‌کنند (مانند فایل‌ها، اتصالات دیتابیس، استریم‌ها)، C# یک ساختار ویژه به نام using را فراهم کرده است که به طور خودکار متد Dispose() را فراخوانی می‌کند، حتی در صورت بروز استثنا. این روش به شدت به بلوک finally برای پاکسازی منابع ارجحیت دارد و کد را خواناتر می‌کند.

try
{
    using (System.IO.StreamReader reader = new System.IO.StreamReader("nonexistent_file.txt"))
    {
        string line = reader.ReadLine();
        Console.WriteLine(line);
    } // reader.Dispose() به طور خودکار در اینجا فراخوانی می‌شود
}
catch (System.IO.FileNotFoundException ex)
{
    Console.WriteLine($"خطا: فایل پیدا نشد! {ex.Message}");
}
catch (Exception ex)
{
    Console.WriteLine($"خطای کلی: {ex.Message}");
}
// هیچ نیازی به بلوک finally برای بستن reader نیست

جزئیات بلوک Catch: فیلترها، انواع استثناها، و سلسله مراتب

درک عمیق‌تر از بلوک catch برای مدیریت مؤثر استثناها بسیار حیاتی است. در این بخش، به بررسی سلسله مراتب کلاس‌های استثنا، نحوه گرفتن چندین استثنا و فیلترهای استثنا می‌پردازیم.

سلسله مراتب کلاس Exception

تمام کلاس‌های استثنا در C# از کلاس پایه System.Exception ارث می‌برند. این یک سلسله مراتب غنی را تشکیل می‌دهد که به شما امکان می‌دهد استثناها را به صورت خاص یا عمومی مدیریت کنید:

• System.Exception: کلاس پایه برای تمام استثناها.
• System.SystemException: کلاس پایه برای استثناهایی که توسط CLR پرتاب می‌شوند (مثلاً NullReferenceException، DivideByZeroException، StackOverflowException). اینها معمولاً نشان‌دهنده خطاهای برنامه‌نویسی یا شرایط زمان اجرا هستند که نباید به صورت معمول مدیریت شوند.
• System.ApplicationException: کلاس پایه پیشنهادی برای استثناهای سفارشی که توسط برنامه‌ها پرتاب می‌شوند و نشان‌دهنده خطاهای منطقی یا تجاری هستند. (هرچند که بهترین رویه فعلی، وراثت مستقیم از System.Exception است).

علاوه بر این، .NET دارای تعداد زیادی استثنای از پیش تعریف شده است که سناریوهای رایج را پوشش می‌دهند:

• System.IO.FileNotFoundException: زمانی که فایل مشخص شده پیدا نمی‌شود.
• System.ArgumentException: زمانی که یک آرگومان متد نامعتبر است.
• System.ArgumentNullException: زمانی که یک آرگومان متد null است.
• System.InvalidOperationException: زمانی که یک عملیات در حالت فعلی شی نامعتبر است.
• System.Net.WebException: خطاهای مرتبط با عملیات وب.

هنگام گرفتن استثناها، از بلوک‌های catch خاص‌تر به سمت بلوک‌های عمومی‌تر حرکت کنید:

try
{
    // کد
}
catch (ArgumentNullException ex)
{
    Console.WriteLine($"خطای آرگومان خالی: {ex.Message}");
}
catch (ArgumentException ex)
{
    Console.WriteLine($"خطای آرگومان: {ex.Message}");
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"خطای فایل: {ex.Message}");
}
catch (Exception ex) // باید آخرین بلوک catch باشد
{
    Console.WriteLine($"خطای عمومی: {ex.Message}");
}

این ترتیب تضمین می‌کند که استثنای خاص مورد نظر قبل از اینکه یک بلوک عمومی‌تر آن را بگیرد، مدیریت شود.

گرفتن بدون نوع خاص (Bare Catch)

می‌توانید یک بلوک catch بدون آرگومان نوع استثنا تعریف کنید (که به آن “bare catch” گفته می‌شود):

try
{
    // کد
}
catch // می‌گیرد هر نوع استثنای پرتاب شده
{
    Console.WriteLine("خطایی رخ داد، اما جزئیات آن نامعلوم است.");
    // در اینجا نمی‌توانید به شیء استثنا دسترسی داشته باشید
}

این روش به شدت توصیه نمی‌شود، زیرا شما به شیء Exception دسترسی ندارید و نمی‌توانید اطلاعاتی مانند پیام خطا، Stack Trace یا نوع دقیق استثنا را لاگ کنید یا از آن استفاده کنید. این بلوک تنها در سناریوهای بسیار خاص (مانند جلوگیری از کراش برنامه در یک لایه UI) ممکن است کاربرد داشته باشد، اما حتی در آن موارد نیز بهتر است catch (Exception ex) استفاده شود تا بتوانید حداقل اطلاعات استثنا را لاگ کنید.

فیلترهای استثنا (Exception Filters) – C# 6 و بالاتر

C# 6 معرفی قابلیت فیلترهای استثنا را با استفاده از کلمه کلیدی when آسان کرد. این قابلیت به شما اجازه می‌دهد تا یک شرط به بلوک catch اضافه کنید. اگر استثنا از نوع مشخص شده باشد و شرط when نیز درست باشد، بلوک catch اجرا خواهد شد. این کار به تمیزتر شدن کد کمک می‌کند، زیرا دیگر نیازی به یک if داخلی در بلوک catch نیست.

void ProcessData(int value)
{
    try
    {
        if (value < 0)
        {
            throw new ArgumentOutOfRangeException(nameof(value), "Value cannot be negative.");
        }
        else if (value == 0)
        {
            throw new DivideByZeroException("Value cannot be zero for division.");
        }
        else if (value > 100)
        {
            throw new InvalidOperationException("Value is too large for current operation.");
        }
        Console.WriteLine($"Processing value: {value}");
    }
    catch (ArgumentOutOfRangeException ex) when (ex.ParamName == "value")
    {
        Console.WriteLine($"خطا: آرگومان 'value' منفی است. {ex.Message}");
    }
    catch (DivideByZeroException ex)
    {
        Console.WriteLine($"خطا: تلاش برای تقسیم بر صفر. {ex.Message}");
    }
    catch (Exception ex) when (ex.Message.Contains("too large"))
    {
        Console.WriteLine($"خطای عملیاتی: مقدار بسیار بزرگ است. {ex.Message}");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"خطای عمومی و نامشخص: {ex.Message}");
    }
}

// مثال استفاده:
ProcessData(-5); // فعال کردن ArgumentOutOfRangeException با فیلتر
ProcessData(0);  // فعال کردن DivideByZeroException
ProcessData(150); // فعال کردن InvalidOperationException با فیلتر
ProcessData(10); // اجرای عادی

مزیت فیلترهای استثنا این است که شرط when قبل از Unwind شدن Stack و ایجاد شیء Exception ارزیابی می‌شود (حداقل به طور نظری، جزئیات پیاده‌سازی CLR ممکن است متفاوت باشد). این به شما امکان می‌دهد استثناها را در صورت عدم تطابق با شرط، دوباره پرتاب (re-throw) کنید بدون اینکه Stack Trace اصلی تغییر کند، که در بخش بعدی توضیح داده می‌شود.

throw; در مقابل throw ex;

یکی از ظریف‌ترین و در عین حال مهم‌ترین جنبه‌های مدیریت استثناها، تفاوت بین throw; و throw ex; در یک بلوک catch است.

• throw ex; (پرتاب مجدد یک شیء استثنای جدید):
  وقتی throw ex; را در بلوک catch استفاده می‌کنید، یک استثنای جدید از نوع ex پرتاب می‌شود. این کار باعث می‌شود Stack Trace فعلی بازنشانی شود و Stack Trace جدید از نقطه throw ex; آغاز شود. این باعث از بین رفتن اطلاعات مهمی در مورد محل اصلی وقوع خطا می‌شود و دیباگینگ را بسیار دشوار می‌کند.

  
  void MethodA()
  {
      try
      {
          MethodB();
      }
      catch (Exception ex)
      {
          // Stack Trace در اینجا از MethodA شروع می‌شود و اطلاعات MethodB از بین می‌رود.
          throw ex; 
      }
  }
  
  void MethodB()
  {
      throw new InvalidOperationException("خطا در MethodB");
  }
  

• throw; (پرتاب مجدد استثنای اصلی):
  وقتی throw; را (بدون آرگومان) در بلوک catch استفاده می‌کنید، همان استثنای اصلی که گرفته شده بود، دوباره پرتاب می‌شود. این کار Stack Trace اصلی را حفظ می‌کند و اجازه می‌دهد تا Stack Trace به درستی به محل وقوع خطای اولیه اشاره کند. این بهترین رویه برای پرتاب مجدد استثناها است.

  
  void MethodA()
  {
      try
      {
          MethodB();
      }
      catch (Exception ex)
      {
          Console.WriteLine($"استثنا گرفته شده در MethodA: {ex.Message}");
          // Stack Trace اصلی MethodB حفظ می‌شود.
          throw; 
      }
  }
  
  void MethodB()
  {
      throw new InvalidOperationException("خطا در MethodB");
  }
  

همیشه سعی کنید از throw; برای پرتاب مجدد استثناها استفاده کنید، مگر اینکه دلیل بسیار موجهی برای از بین بردن Stack Trace اصلی داشته باشید (که معمولاً نیست). اگر نیاز به اضافه کردن اطلاعات جدید به استثنا دارید، می‌توانید یک استثنای جدید پرتاب کنید که استثنای اصلی را به عنوان InnerException خود شامل شود.

ایجاد و پرتاب استثناهای سفارشی

گاهی اوقات، استثناهای استاندارد .NET برای بیان شرایط خطای خاص در منطق تجاری برنامه شما کافی نیستند. در این مواقع، ایجاد استثناهای سفارشی (Custom Exceptions) راه حل مناسبی است. استثناهای سفارشی به شما امکان می‌دهند تا اطلاعات معنی‌دارتر و خاص‌تری را در مورد خطاهای تجاری یا دامنه خود منتقل کنید، که این امر به بهبود خوانایی کد، قابلیت نگهداری و دیباگینگ کمک می‌کند.

چرا به استثناهای سفارشی نیاز داریم؟

• معناداری (Meaningfulness): استثناهای استاندارد ممکن است برای بیان خطاهایی مانند “موجودی کافی نیست” یا “کاربر غیرفعال است” نامناسب باشند. استثناهای سفارشی نام‌های گویا و مشخصی برای این شرایط فراهم می‌کنند.
• جداسازی نگرانی‌ها (Separation of Concerns): با استثناهای سفارشی، می‌توانید منطق مدیریت خطای مرتبط با دامنه خاص خود را از خطاهای سیستمی عمومی جدا کنید.
• انتقال اطلاعات بیشتر: می‌توانید ویژگی‌های اضافی (properties) به استثنای سفارشی خود اضافه کنید تا جزئیات بیشتری در مورد خطا (مانند کد خطا، شناسه تراکنش، یا مقادیر داده‌ای خاص) را منتقل کنید.
• کنترل بیشتر: به شما امکان می‌دهد که چگونه استثناها در لایه‌های مختلف برنامه شما مدیریت و فیلتر شوند.

نحوه تعریف یک کلاس استثنای سفارشی

یک کلاس استثنای سفارشی باید از System.Exception ارث ببرد. طبق بهترین رویه‌ها، باید حداقل سه سازنده (Constructor) استاندارد را پیاده‌سازی کنید:

1. سازنده بدون آرگومان: برای استفاده عمومی.
2. سازنده با یک آرگومان string message: برای ارائه یک پیام خطای مشخص.
3. سازنده با string message و Exception innerException: برای نگهداری اطلاعات استثنای اصلی که منجر به پرتاب این استثنای جدید شده است (InnerException). این بسیار مهم است، زیرا Stack Trace استثنای اصلی را حفظ می‌کند.

همچنین، توصیه می‌شود کلاس استثنای خود را با ویژگی [Serializable] علامت‌گذاری کنید تا بتواند در سناریوهای Serialization (مانند ارسال استثنا بین فرآیندها یا از طریق شبکه) به درستی کار کند.

using System;
using System.Runtime.Serialization;

// 1. کلاس استثنای سفارشی
[Serializable]
public class InsufficientFundsException : Exception
{
    public decimal RequestedAmount { get; }
    public decimal AvailableBalance { get; }

    // 1. سازنده بدون آرگومان
    public InsufficientFundsException() { }

    // 2. سازنده با پیام خطا
    public InsufficientFundsException(string message) 
        : base(message) { }

    // 3. سازنده با پیام خطا و Inner Exception
    public InsufficientFundsException(string message, Exception innerException)
        : base(message, innerException) { }

    // 4. سازنده برای Serialization (اجباری برای کلاس‌های استثنای سفارشی)
    protected InsufficientFundsException(SerializationInfo info, StreamingContext context)
        : base(info, context)
    {
        // بازیابی مقادیر ویژگی‌های سفارشی
        RequestedAmount = info.GetDecimal(nameof(RequestedAmount));
        AvailableBalance = info.GetDecimal(nameof(AvailableBalance));
    }

    // سازنده‌ای با ویژگی‌های خاص استثنا
    public InsufficientFundsException(decimal requestedAmount, decimal availableBalance)
        : base($"Not enough funds. Requested: {requestedAmount}, Available: {availableBalance}")
    {
        RequestedAmount = requestedAmount;
        AvailableBalance = availableBalance;
    }

    // متد برای Serialization ویژگی‌های سفارشی
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        base.GetObjectData(info, context);
        info.AddValue(nameof(RequestedAmount), RequestedAmount);
        info.AddValue(nameof(AvailableBalance), AvailableBalance);
    }
}

// 2. کلاسی که از استثنای سفارشی استفاده می‌کند
public class Account
{
    public decimal Balance { get; private set; }

    public Account(decimal initialBalance)
    {
        Balance = initialBalance;
    }

    public void Withdraw(decimal amount)
    {
        if (amount <= 0)
        {
            throw new ArgumentException("Withdrawal amount must be positive.", nameof(amount));
        }

        if (Balance < amount)
        {
            // پرتاب استثنای سفارشی با جزئیات بیشتر
            throw new InsufficientFundsException(amount, Balance); 
        }

        Balance -= amount;
        Console.WriteLine($"Successfully withdrew {amount}. New balance: {Balance}");
    }
}

// 3. نحوه گرفتن استثنای سفارشی
public class BankApp
{
    public static void SimulateTransaction()
    {
        Account myAccount = new Account(100.0m);

        try
        {
            Console.WriteLine("Attempting to withdraw 50...");
            myAccount.Withdraw(50.0m);

            Console.WriteLine("Attempting to withdraw 70...");
            myAccount.Withdraw(70.0m); // این خط InsufficientFundsException را پرتاب می‌کند
        }
        catch (InsufficientFundsException ex)
        {
            Console.WriteLine($"خطای برداشت: {ex.Message}");
            Console.WriteLine($"مبلغ درخواستی: {ex.RequestedAmount}, موجودی فعلی: {ex.AvailableBalance}");
            // لاگ کردن یا اطلاع رسانی به کاربر
        }
        catch (ArgumentException ex)
        {
            Console.WriteLine($"خطای آرگومان: {ex.Message}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"خطای غیرمنتظره: {ex.Message}");
        }
    }
}

// برای تست:
// BankApp.SimulateTransaction();

در مثال بالا، InsufficientFundsException اطلاعات معنی‌داری (مبلغ درخواستی و موجودی فعلی) را به همراه پیام خطا ارائه می‌دهد که به بلوک catch اجازه می‌دهد تا به طور هوشمندانه‌تر با وضعیت برخورد کند و اطلاعات مفیدتری به کاربر نشان دهد یا لاگ کند.

مدیریت استثناهای کنترل‌نشده و رویدادهای Global

حتی با بهترین استراتژی‌های try-catch، ممکن است استثناهایی وجود داشته باشند که به طور صریح گرفته نشده‌اند (Unhandled Exceptions). این استثناها در صورتی که به بالاترین سطح برنامه برسند و توسط هیچ بلوک catchای گرفته نشوند، منجر به کراش شدن برنامه و خروج ناگهانی آن می‌شوند. در بسیاری از موارد، این وضعیت برای کاربر تجربه نامطلوبی ایجاد می‌کند و از دید توسعه‌دهنده، فرصت لاگ کردن اطلاعات مهم برای دیباگینگ از دست می‌رود.

برای مدیریت این استثناهای کنترل‌نشده، .NET رویدادهای Global (سراسری) را فراهم کرده است که به شما اجازه می‌دهند قبل از اینکه برنامه کاملاً متوقف شود، وارد عمل شوید و اطلاعات خطا را ثبت کنید.

AppDomain.CurrentDomain.UnhandledException

این رویداد برای تمام انواع برنامه‌های .NET (کنسول، Windows Forms، WPF، ASP.NET Core و ...) زمانی فراخوانی می‌شود که یک استثنا در یک Thread کنترل‌نشده باشد. این رویداد در سطح AppDomain اتفاق می‌افتد. شما می‌توانید یک Event Handler برای این رویداد ثبت کنید تا اطلاعات استثنا را لاگ کنید یا اقدامات بازیابی اولیه را انجام دهید.

using System;
using System.IO;

public class UnhandledExceptionExample
{
    public static void Main()
    {
        // ثبت رویداد UnhandledException
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

        Console.WriteLine("برنامه شروع شد.");

        try
        {
            // این بخش به صورت عمدی استثنایی را ایجاد می‌کند که گرفته نخواهد شد
            string path = "non_existent_directory\\test.txt";
            File.ReadAllText(path); // این خط FileNotFoundException یا DirectoryNotFoundException پرتاب می‌کند
        }
        catch (DivideByZeroException ex) // این catch فقط برای DivideByZeroException است
        {
            Console.WriteLine($"این استثنا هرگز گرفته نخواهد شد: {ex.Message}");
        }

        Console.WriteLine("این خط کد احتمالا اجرا نخواهد شد اگر استثنا کنترل نشده باشد.");
        Console.ReadKey();
    }

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        // در اینجا می‌توانید اطلاعات استثنا را لاگ کنید
        Exception ex = (Exception)e.ExceptionObject;
        Console.ForegroundColor = ConsoleColor.Red;
        Console.WriteLine("\n*** یک استثنای کنترل نشده رخ داده است! ***");
        Console.WriteLine($"نوع استثنا: {ex.GetType().Name}");
        Console.WriteLine($"پیام: {ex.Message}");
        Console.WriteLine($"Stack Trace:\n{ex.StackTrace}");

        // اگر e.IsTerminating درست باشد، یعنی CLR در حال خاتمه دادن به برنامه است.
        // در این نقطه، می‌توانید به کاربر اطلاع دهید و/یا برنامه را به صورت graceful shutdown کنید.
        if (e.IsTerminating)
        {
            Console.WriteLine("\nبرنامه به دلیل استثنا در حال خاتمه است.");
            // اینجا می‌توانید کدهای پاکسازی نهایی را اجرا کنید
        }
        Console.ResetColor();
    }
}

نکته مهم: پس از فراخوانی UnhandledException، CLR معمولاً برنامه را خاتمه می‌دهد. نمی‌توانید با گرفتن استثنا در این رویداد، از کراش شدن برنامه جلوگیری کنید. هدف اصلی این رویداد، ثبت اطلاعات خطا قبل از خاتمه است.

Application.ThreadException (برای Windows Forms)

برای برنامه‌های Windows Forms، یک رویداد خاص‌تر برای استثناهایی که در Thread اصلی UI کنترل نشده‌اند، وجود دارد: Application.ThreadException. این رویداد به شما امکان می‌دهد تا یک پیام خطای کاربرپسند را نمایش دهید و حتی انتخاب کنید که برنامه ادامه یابد یا خاتمه یابد.

using System;
using System.Windows.Forms;

public class WinFormsApp : Form
{
    public WinFormsApp()
    {
        this.Text = "Unhandled Exception Demo";
        Button btn = new Button { Text = "Throw Exception", Location = new System.Drawing.Point(50, 50) };
        btn.Click += (sender, e) => 
        {
            // ایجاد یک استثنای کنترل نشده در Thread UI
            int x = 10 / (int.Parse("0")); 
        };
        this.Controls.Add(btn);
    }

    [STAThread]
    public static void Main()
    {
        // ثبت رویداد ThreadException
        Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
        // تنظیم UnhandledException برای گرفتن استثناهای خارج از UI thread یا fallback
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

        Application.Run(new WinFormsApp());
    }

    static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
    {
        // نمایش یک پیغام خطای کاربرپسند
        string errorMessage = "یک خطای کنترل نشده در برنامه رخ داده است:\n\n" +
                              e.Exception.Message + "\n\n" +
                              "آیا مایلید ادامه دهید؟ (این کار ممکن است منجر به ناپایداری شود)";
        DialogResult result = MessageBox.Show(errorMessage, "خطای برنامه", MessageBoxButtons.YesNo, MessageBoxIcon.Error);

        if (result == DialogResult.No)
        {
            Application.Exit(); // خاتمه دادن به برنامه
        }
        // در غیر این صورت، برنامه تلاش می‌کند ادامه دهد (ممکن است ناپایدار شود)
        // اینجا هم می‌توانید لاگ‌نویسی کنید
        Console.WriteLine($"WinForms UI Thread Exception: {e.Exception.Message}");
    }

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        // این رویداد برای استثناهای غیر UI Thread یا به عنوان fallback استفاده می‌شود
        Exception ex = (Exception)e.ExceptionObject;
        Console.WriteLine($"Global Unhandled Exception (AppDomain): {ex.Message}");
        // لاگ کنید و/یا خاتمه دهید
    }
}

TaskScheduler.UnobservedTaskException (برای TAP)

با معرفی Task-based Asynchronous Pattern (TAP) و کلاس Task، مدیریت استثناها در کدهای ناهمزمان کمی متفاوت شد. استثناهایی که در یک Task رخ می‌دهند و توسط await گرفته نمی‌شوند یا به پراپرتی Exception تسک دسترسی پیدا نمی‌شود، به عنوان "Unobserved Exceptions" شناخته می‌شوند. این استثناها در گذشته می‌توانستند منجر به کراش شدن برنامه شوند، اما از .NET Framework 4.5 به بعد، رفتار تغییر کرده و به طور پیش‌فرض، این استثناها به سادگی لاگ می‌شوند و برنامه کراش نمی‌کند.

با این حال، همچنان می‌توانید رویداد TaskScheduler.UnobservedTaskException را برای لاگ کردن یا مدیریت این استثناها استفاده کنید:

using System;
using System.Threading.Tasks;

public class AsyncExceptionExample
{
    public static async Task Main()
    {
        // ثبت رویداد UnobservedTaskException
        TaskScheduler.UnobservedTaskException += (sender, e) =>
        {
            Console.ForegroundColor = ConsoleColor.Yellow;
            Console.WriteLine($"\n*** Unobserved Task Exception: {e.Exception.Message} ***");
            foreach (var innerEx in e.Exception.InnerExceptions)
            {
                Console.WriteLine($"  Inner Exception: {innerEx.Message}");
            }
            e.SetObserved(); // اعلام می‌کنیم که استثنا مشاهده شده است و نباید کراش کند (مربوط به رفتار قدیمی‌تر)
            Console.ResetColor();
        };

        Console.WriteLine("شروع برنامه ناهمزمان...");

        try
        {
            // تسکی که استثنایی را پرتاب می‌کند
            Task task = Task.Run(() => 
            {
                throw new InvalidOperationException("این یک استثنای کنترل نشده در تسک است!");
            });

            // مهم: عدم await کردن یا بررسی task.Exception باعث می‌شود استثنا "unobserved" شود.
            // به تسک کمی زمان می‌دهیم تا اجرا شود
            await Task.Delay(1000); 

            // فراخوانی GC برای تحریک UnobservedTaskException
            // این کار تضمینی نیست و فقط برای دمو است
            GC.Collect();
            GC.WaitForPendingFinalizers();

            Console.WriteLine("برنامه پس از تاخیر ادامه یافت.");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"استثنای گرفته شده در Main: {ex.Message}");
        }

        Console.WriteLine("پایان برنامه.");
        Console.ReadKey();
    }
}

توضیح: از .NET 4.5 به بعد، Unobserved Task Exceptions به طور پیش‌فرض منجر به کراش برنامه نمی‌شوند، بلکه فقط در Event Log سیستم ثبت می‌شوند. فراخوانی e.SetObserved() در Event Handler باعث می‌شود که CLR آن را "مشاهده شده" در نظر بگیرد و از ثبت مجدد آن در Event Log جلوگیری کند.

استفاده از این رویدادهای Global یک لایه نهایی از محافظت را برای برنامه شما فراهم می‌کند، اما هرگز جایگزین مدیریت استثناهای محلی با try-catch در نقاط مناسب کد نیستند. هدف اصلی آنها، لاگ کردن خطاها برای اهداف عیب‌یابی و تجزیه و تحلیل است، نه بازیابی از خطا.

بهترین رویه‌ها و الگوهای طراحی در مدیریت خطا

مدیریت خطا فقط درباره نوشتن بلوک‌های try-catch-finally نیست؛ بلکه یک جنبه کلیدی از طراحی نرم‌افزار است. رویکرد صحیح به مدیریت استثناها می‌تواند تأثیر زیادی بر پایداری، قابلیت نگهداری و عملکرد برنامه شما داشته باشد. در ادامه به برخی از بهترین رویه‌ها و الگوهای طراحی اشاره می‌شود:

۱. Fail Fast (به سرعت شکست بخورید)

اصل "Fail Fast" به این معنی است که برنامه شما باید به محض شناسایی یک حالت نامعتبر یا خطا، متوقف شود یا یک استثنا را پرتاب کند. این کار به جلوگیری از ادامه اجرای برنامه در یک حالت ناپایدار کمک می‌کند و دیباگینگ را آسان‌تر می‌کند، زیرا خطا در نزدیک‌ترین نقطه به وقوع آن آشکار می‌شود.

• استفاده از Guard Clauses: برای بررسی پیش‌شرط‌های ورودی متدها از if و پرتاب ArgumentException یا ArgumentNullException در ابتدای متد استفاده کنید.

public void ProcessOrder(Order order)
{
    if (order == null)
    {
        throw new ArgumentNullException(nameof(order), "Order cannot be null.");
    }
    if (order.Items.Count == 0)
    {
        throw new ArgumentException("Order must contain at least one item.", nameof(order));
    }
    // ادامه پردازش سفارش
}

۲. "Don't Catch 'Em All" (همه استثناها را نگیرید)

از گرفتن System.Exception در هر لایه از برنامه خودداری کنید، مگر اینکه دلیل موجهی برای آن داشته باشید (مثلاً در بالاترین لایه برای لاگ کردن و نمایش یک پیام عمومی به کاربر). گرفتن همه استثناها می‌تواند مشکلات زیر را ایجاد کند:

• پنهان کردن خطاها: خطاهای برنامه‌نویسی یا سیستمی مهم ممکن است بدون توجه پنهان شوند.
• مغایرت با اصل Fail Fast: برنامه ممکن است با وجود خطاهای اساسی به کار خود ادامه دهد.
• دیباگینگ دشوار: ردیابی علت اصلی خطا بسیار سخت‌تر می‌شود.

فقط استثناهایی را بگیرید که می‌دانید چگونه با آن‌ها کنار بیایید و می‌توانید به درستی از آنها بازیابی شوید. در غیر این صورت، اجازه دهید استثنا به لایه بالاتر منتشر شود.

۳. استفاده هوشمندانه از finally برای پاکسازی منابع

همانطور که قبلاً ذکر شد، finally برای تضمین پاکسازی منابع حیاتی است. اما بهترین روش برای منابعی که IDisposable را پیاده‌سازی می‌کنند، استفاده از کلمه کلیدی using است که به طور خودکار Dispose() را فراخوانی می‌کند.

احتیاط: هرگز در بلوک finally استثنا پرتاب نکنید. اگر در finally استثنا پرتاب شود و استثنایی در try نیز رخ داده باشد، استثنای اصلی از بین می‌رود و دیباگینگ بسیار دشوار می‌شود.

۴. طراحی API: چه زمانی یک متد باید استثنا پرتاب کند؟

• برای شرایط استثنایی (Exceptional Conditions): اگر یک متد نمی‌تواند وظیفه مورد نظر خود را به دلیل شرایطی که خارج از کنترل عادی جریان برنامه است (مانند عدم وجود یک فایل، عدم دسترسی به شبکه، یا داده‌های ورودی کاملاً نامعتبر) انجام دهد، باید یک استثنا پرتاب کند.
• اجتناب از استفاده از استثناها برای کنترل جریان عادی (Control Flow): استثناها نباید برای هدایت جریان عادی برنامه استفاده شوند. مثلاً، برای بررسی اینکه آیا یک آیتم در یک مجموعه وجود دارد یا خیر، به جای پرتاب و گرفتن ItemNotFoundException، از متدهایی مانند ContainsKey() یا TryParse() استفاده کنید.

// بد: استفاده از استثنا برای کنترل جریان عادی
try
{
    var user = GetUserById(id); // ممکن است UserNotFoundException پرتاب کند
    // استفاده از user
}
catch (UserNotFoundException)
{
    Console.WriteLine("کاربر پیدا نشد.");
}

// خوب: استفاده از Try-Pattern
if (TryGetUserById(id, out var user))
{
    // استفاده از user
}
else
{
    Console.WriteLine("کاربر پیدا نشد.");
}

// مثال پیاده‌سازی TryGetUserById
public bool TryGetUserById(int id, out User user)
{
    user = null;
    // منطق بازیابی کاربر
    if (id == 1) // فرض کنید کاربر 1 وجود دارد
    {
        user = new User { Id = 1, Name = "Test User" };
        return true;
    }
    return false;
}

۵. کپسوله‌سازی استثناها (Exception Encapsulation/Wrapping)

در سیستم‌های لایه‌ای، ممکن است بخواهید استثناهای سطح پایین را در استثناهای سطح بالاتر کپسوله‌سازی کنید. این کار به پنهان کردن جزئیات پیاده‌سازی از لایه‌های بیرونی کمک می‌کند و استثناهای معنی‌دارتری را برای لایه مصرف‌کننده فراهم می‌کند. از پراپرتی InnerException برای حفظ Stack Trace استثنای اصلی استفاده کنید.

public class DataAccessException : Exception 
{
    public DataAccessException(string message, Exception innerException) 
        : base(message, innerException) { }
}

public class UserService
{
    public User GetUser(int userId)
    {
        try
        {
            // فراخوانی متد لایه دسترسی به داده
            return _userRepository.GetUserFromDatabase(userId); 
        }
        catch (SqlException ex) // گرفتن یک استثنای سطح پایین‌تر
        {
            // پرتاب یک استثنای سطح بالاتر با حفظ InnerException
            throw new DataAccessException($"خطا در بازیابی کاربر با شناسه {userId}.", ex); 
        }
    }
}

۶. پرتاب مجدد (Re-throwing) استثنا با throw;

همانطور که در بخش‌های قبلی توضیح داده شد، همیشه از throw; (بدون آرگومان) برای پرتاب مجدد استثناها استفاده کنید تا Stack Trace اصلی حفظ شود. این برای دیباگینگ بسیار حیاتی است.

۷. مستندسازی استثناها

از کامنت‌های XML (/// ) برای مستندسازی استثناهایی که یک متد ممکن است پرتاب کند، استفاده کنید. این به توسعه‌دهندگان مصرف‌کننده کمک می‌کند تا متوجه شوند چه استثناهایی را باید انتظار داشته باشند و چگونه آنها را مدیریت کنند.

/// 

/// پردازش یک سفارش مشتری.
/// 
/// شیء سفارش برای پردازش.
/// اگر سفارش null باشد.
/// اگر سفارش آیتمی نداشته باشد.
/// اگر موجودی مشتری کافی نباشد.
public void ProcessOrder(Order order)
{
    // ...
}

۸. تست‌پذیری (Testability)

مدیریت استثناها باید تست‌پذیر باشد. این به معنای این است که شما باید قادر باشید سناریوهایی را شبیه‌سازی کنید که در آن استثناها پرتاب می‌شوند و اطمینان حاصل کنید که کد شما به درستی با آن‌ها برخورد می‌کند. این اغلب شامل استفاده از Mocking Frameworks برای شبیه‌سازی رفتار متدهایی است که ممکن است استثنا پرتاب کنند.

با رعایت این بهترین رویه‌ها و الگوهای طراحی، می‌توانید یک استراتژی مدیریت خطای مؤثر و قابل اعتماد را در برنامه‌های C# خود پیاده‌سازی کنید.

تاثیر مدیریت خطا بر عملکرد (Performance Implications)

مدیریت استثناها ابزاری قدرتمند برای افزایش پایداری و قابلیت اطمینان نرم‌افزار است، اما استفاده نادرست از آن می‌تواند تأثیر منفی قابل توجهی بر عملکرد (Performance) برنامه داشته باشد. پرتاب و گرفتن استثناها فرآیندهایی گران‌قیمت هستند و نباید برای کنترل جریان عادی برنامه استفاده شوند.

چرا پرتاب استثنا گران است؟

وقتی یک استثنا پرتاب می‌شود، CLR (Common Language Runtime) مجموعه‌ای از عملیات‌های پرهزینه را انجام می‌دهد:

1. Gathering Stack Trace (جمع‌آوری Stack Trace): مهمترین دلیل سربار عملکردی، فرآیند جمع‌آوری Stack Trace است. CLR باید به عقب برگردد و اطلاعات مربوط به تمام فراخوانی‌های متد در Stack فعلی را جمع‌آوری کند تا Stack Trace کاملی از نقطه وقوع خطا تا نقطه پرتاب استثنا بسازد. این شامل بررسی متادیتای متدها و JIT-کامپایل بخش‌هایی از کد است که ممکن است هنوز کامپایل نشده باشند.
2. Object Creation (ایجاد شیء): هر استثنا یک شیء است و ایجاد شیء در حافظه سربار دارد، هرچند که معمولاً این بخش کمترین تأثیر را دارد.
3. Exception Handling Mechanism (مکانیزم مدیریت استثنا): CLR دارای یک مکانیزم داخلی برای مدیریت استثناها است که شامل جستجو برای بلوک catch مناسب در Stack فراخوانی است. این فرآیند نیز مقداری سربار دارد.
4. Context Switching (سوئیچینگ زمینه): پرتاب استثنا می‌تواند باعث تغییر جریان برنامه و پرش به بلوک catch شود، که شامل تغییرات در context اجرایی است.

در مقایسه با بررسی‌های شرطی ساده (if-else) یا استفاده از کدهای بازگشتی (Error Codes)، هزینه پرتاب و گرفتن یک استثنا به مراتب بالاتر است. این هزینه می‌تواند در حد ده‌ها تا صدها برابر بیشتر باشد.

چه زمانی نباید از استثناها برای کنترل جریان برنامه استفاده کرد؟

قانون کلی این است: استثناها برای شرایط استثنایی هستند، نه برای شرایط عادی.

• بررسی ورودی‌های رایج: برای بررسی اعتبار ورودی‌ها در متدها، به جای پرتاب و گرفتن ArgumentException برای هر سناریوی نامعتبر، از if-else و کدهای بازگشتی یا Try-Pattern استفاده کنید.

  
  // بد: استفاده از استثنا برای کنترل جریان عادی
  public bool TryParseNumberBad(string input, out int result)
  {
      try
      {
          result = int.Parse(input);
          return true;
      }
      catch (FormatException)
      {
          result = 0;
          return false;
      }
  }
  
  // خوب: استفاده از Try-Pattern داخلی .NET
  public bool TryParseNumberGood(string input, out int result)
  {
      return int.TryParse(input, out result);
  }
          

  متد int.TryParse مثالی عالی از یک الگوی خوب است که از پرتاب استثنا برای شرایطی که به طور معمول انتظار می‌رود (ورودی نامعتبر) جلوگیری می‌کند.

• عملیات‌های مورد انتظار که ممکن است شکست بخورند: اگر در یک حلقه قرار دارید و انتظار دارید که برخی از عملیات‌ها به طور مکرر شکست بخورند (مثلاً تلاش برای اتصال به یک سرویس خارجی که ممکن است گاهی اوقات در دسترس نباشد)، سعی کنید از مکانیزم‌های دیگری به جای استثناها استفاده کنید، مگر اینکه شکست به معنای توقف کامل عملیات باشد.

سناریوهایی که استثناها اجتناب‌ناپذیرند:

علیرغم سربار عملکردی، استثناها در سناریوهای زیر همچنان بهترین راه حل هستند:

• خطاهای سیستمی/محیطی: مانند FileNotFoundException، OutOfMemoryException، NetworkConnectionException. اینها شرایطی هستند که برنامه نمی‌تواند به صورت عادی ادامه دهد و نشان‌دهنده یک مشکل اساسی هستند.
• خطاهای منطقی/تجاری غیرقابل بازیابی: مانند InsufficientFundsException در مثال بانکی، اگر یک تراکنش نمی‌تواند انجام شود و این یک وضعیت واقعاً استثنایی است که نباید نادیده گرفته شود.
• نقض Invariantها: زمانی که یک شیء به حالت نامعتبر داخلی می‌رود یا یک قانون کلیدی سیستم نقض می‌شود.

تکنیک‌هایی برای کاهش سربار:

• Per-function / Per-block catch: استثناها را در نزدیک‌ترین نقطه که می‌توانید منطق بازیابی یا لاگ کردن را انجام دهید، بگیرید. نیازی نیست که استثناها را بیش از حد به بالا ببرید.
• Unwinding Stack Trace: همانطور که قبلاً ذکر شد، استفاده از throw; (بدون آرگومان) برای پرتاب مجدد استثنا به جای throw ex; باعث می‌شود Stack Trace یک بار جمع‌آوری شود، نه چندین بار.
• Lazy Stack Trace generation: در برخی موارد، می‌توانید با نادیده گرفتن Stack Trace، در زمان پرتاب استثنا صرفه‌جویی کنید، اما این کار به شدت توصیه نمی‌شود زیرا اطلاعات حیاتی دیباگینگ را از دست می‌دهید. این روش بیشتر در سناریوهای بسیار خاص و با تحلیل دقیق عملکردی توجیه می‌شود.
• فیلترهای استثنا (Exception Filters): در C# 6+, فیلترهای استثنا با when می‌توانند کمی به عملکرد کمک کنند، زیرا شرط when قبل از Unwind شدن Stack و ایجاد شیء Exception ارزیابی می‌شود. اگر شرط False باشد، Stack Unwind نمی‌شود و استثنا به لایه بالاتر منتقل می‌شود.

در نهایت، مدیریت استثناها یک تعادل بین پایداری، خوانایی کد و عملکرد است. از استثناها به عنوان ابزاری برای مدیریت شرایط غیرعادی واقعی استفاده کنید و از سوءاستفاده از آنها برای کنترل جریان عادی برنامه خودداری نمایید.

ثبت و پایش استثناها (Logging and Monitoring Exceptions)

مدیریت خطا تنها به گرفتن استثناها محدود نمی‌شود؛ بخش حیاتی آن، ثبت (Logging) و پایش (Monitoring) استثناها است. لاگ‌ها و سیستم‌های پایش به شما امکان می‌دهند تا مشکلات را در محیط‌های تولیدی شناسایی، تحلیل و رفع کنید، حتی قبل از اینکه کاربران متوجه آنها شوند. این اطلاعات برای بهبود مستمر کیفیت نرم‌افزار، عیب‌یابی و تصمیم‌گیری‌های استراتژیک ضروری هستند.

اهمیت لاگ کردن استثناها

• عیب‌یابی (Troubleshooting): لاگ‌ها مهمترین منبع برای تشخیص و رفع مشکلات در محیط تولید هستند. بدون لاگ‌های کافی، دیباگ کردن مشکلات گزارش شده توسط کاربران تقریباً غیرممکن است.
• پایش سلامت برنامه (Application Health Monitoring): با تحلیل الگوهای استثناها در طول زمان، می‌توانید مشکلات پنهان، نقاط ضعف سیستم، یا افزایش ناگهانی خطاها را که نشان‌دهنده یک مشکل بزرگتر است، شناسایی کنید.
• افزایش قابلیت اطمینان: با ثبت دقیق خطاها، می‌توانید ریشه‌یابی (Root Cause Analysis) کنید و با بهبود کد، از تکرار مجدد خطاها جلوگیری نمایید.
• شواهد و مراجعات قانونی/نظارتی: در برخی صنایع، ثبت دقیق تراکنش‌ها و خطاها برای اهداف حسابرسی یا رعایت مقررات ضروری است.

اطلاعاتی که باید لاگ شوند

هنگام لاگ کردن یک استثنا، اطلاعات زیر باید ثبت شوند تا لاگ‌ها مفید باشند:

• پیام خطا (Error Message): Exception.Message
• نوع استثنا (Exception Type): Exception.GetType().FullName (نام کامل کلاس استثنا)
• Stack Trace: Exception.StackTrace (بسیار حیاتی برای تشخیص محل وقوع خطا)
• Inner Exception: اگر استثنا دارای InnerException است، جزئیات آن نیز باید لاگ شود. این اطلاعات زنجیره علت و معلولی خطا را نشان می‌دهد.
• زمان وقوع: Timestamp دقیق با منطقه زمانی.
• محیط: نام سرور، نسخه برنامه، سیستم عامل و ...
• اطلاعات کاربر: شناسه کاربر یا نام کاربری که عملیات را انجام می‌داده است (در صورت وجود و بدون افشای اطلاعات حساس).
• داده‌های متنی (Contextual Data): هرگونه اطلاعات اضافی که در زمان وقوع خطا مفید است (مانند شناسه تراکنش، پارامترهای ورودی متد، حالت شیء، URL درخواست در وب، نام متد).
• سطح لاگ (Log Level): (مثلاً Error, Warn, Info, Debug) برای فیلتر کردن لاگ‌ها.

لاگ‌های ساختاریافته (Structured Logging) به شدت توصیه می‌شوند، زیرا این امکان را فراهم می‌کنند که لاگ‌ها به راحتی توسط ابزارهای پایش و جستجو (مانند ELK Stack یا Splunk) تجزیه و تحلیل شوند.

ابزارهای لاگینگ (Logging Frameworks)

.NET دارای قابلیت‌های لاگینگ داخلی است (مانند System.Diagnostics.Trace و Console.WriteLine)، اما برای برنامه‌های جدی، استفاده از یک فریم‌ورک لاگینگ تخصصی ضروری است. این فریم‌ورک‌ها قابلیت‌های پیشرفته‌ای مانند پیکربندی خروجی‌های مختلف (فایل، دیتابیس، کنسول، سرویس ابری)، فیلترینگ، لاگ‌های ساختاریافته و مدیریت Performance را فراهم می‌کنند.

• NLog: یکی از فریم‌ورک‌های لاگینگ محبوب و قدرتمند در .NET است که قابلیت‌های انعطاف‌پذیر و کارایی بالایی دارد.
• Serilog: یک فریم‌ورک لاگینگ محبوب دیگر که تمرکز زیادی بر لاگ‌های ساختاریافته دارد و از سینک‌های (sinks) زیادی برای ارسال لاگ‌ها به مقصدهای مختلف پشتیبانی می‌کند.
• Log4Net: یک فریم‌ورک قدیمی‌تر اما همچنان پرکاربرد، برگرفته از Log4j جاوا.
• Microsoft.Extensions.Logging: فریم‌ورک لاگینگ داخلی .NET Core/.NET 5+ که به عنوان یک انتزاع عمل می‌کند و به شما امکان می‌دهد تا لاگینگ را به فریم‌ورک‌های دیگر متصل کنید.

// مثال با Serilog
using Serilog;
using Serilog.Events;

public class LoggingExample
{
    public static void SetupLogging()
    {
        Log.Logger = new LoggerConfiguration()
            .MinimumLevel.Debug()
            .WriteTo.Console(outputTemplate: "{Timestamp:HH:mm:ss} [{Level:u3}] {Message:lj}{NewLine}{Exception}")
            .WriteTo.File("logs/myapp.txt", rollingInterval: RollingInterval.Day)
            .CreateLogger();
    }

    public static void PerformOperation()
    {
        SetupLogging();
        Log.Information("عملیات آغاز شد.");

        try
        {
            int numerator = 10;
            int denominator = 0;
            if (denominator == 0)
            {
                // لاگ اطلاعات contextual قبل از پرتاب استثنا
                Log.Warning("تلاش برای تقسیم بر صفر با مقدار دهنده {DenominatorValue}", denominator);
                throw new DivideByZeroException("نمی‌توان بر صفر تقسیم کرد.");
            }
            int result = numerator / denominator;
            Log.Information($"نتیجه: {result}");
        }
        catch (Exception ex)
        {
            // لاگ کردن استثنا با تمام جزئیات و اطلاعات contextual
            Log.Error(ex, "خطایی در حین انجام عملیات رخ داد.");
        }

        Log.Information("عملیات پایان یافت.");
        Log.CloseAndFlush();
    }
}

// برای تست:
// LoggingExample.PerformOperation();

سیستم‌های پایش و تجمیع لاگ (Log Aggregation and Monitoring Systems)

در برنامه‌های توزیع شده یا بزرگ، لاگ‌ها از منابع مختلفی (سرورها، سرویس‌ها، کلاینت‌ها) می‌آیند. برای مدیریت این حجم از داده‌ها، به سیستم‌های تجمیع و پایش لاگ نیاز دارید:

• ELK Stack (Elasticsearch, Logstash, Kibana): یک مجموعه قدرتمند و متن‌باز برای جمع‌آوری، پردازش، ذخیره‌سازی، جستجو و بصری‌سازی لاگ‌ها.
• Splunk: یک پلتفرم تجاری برای پایش و تحلیل داده‌های ماشین، از جمله لاگ‌ها.
• Azure Application Insights / AWS CloudWatch: سرویس‌های ابری برای پایش عملکرد و لاگینگ برنامه‌ها.
• Sentry / Raygun / AppDynamics: ابزارهای تخصصی برای پایش خطاهای زمان اجرا و مدیریت استثناها، که گزارش‌های دقیق، هشدارها و تحلیل‌های مربوط به خطاها را ارائه می‌دهند.

استفاده از این ابزارها به شما امکان می‌دهد تا دید جامعی از سلامت برنامه خود داشته باشید، سریعاً به مشکلات واکنش نشان دهید و روند بهبود کیفیت نرم‌افزار را تسهیل کنید.

نتیجه‌گیری: استراتژی جامع مدیریت خطا

مدیریت استثناها در C# چیزی فراتر از صرفاً نوشتن بلوک‌های try-catch-finally است. این یک رویکرد جامع و استراتژیک است که باید در تمام مراحل طراحی، توسعه و پایش نرم‌افزار مد نظر قرار گیرد. یک استراتژی مدیریت خطای موثر نه تنها برنامه شما را در برابر اتفاقات پیش‌بینی‌نشده مقاوم‌تر می‌سازد، بلکه به بهبود قابلیت نگهداری کد، تجربه کاربری و فرآیند دیباگینگ کمک شایانی می‌کند.

در طول این مقاله، ما به جنبه‌های مختلف مدیریت خطا پرداختیم:

• درک ضرورت مدیریت خطا و تمایز آن از سایر انواع خطاها.
• مبانی try-catch-finally به عنوان ستون فقرات مدیریت استثناها در C#.
• جزئیات پیشرفته بلوک catch، شامل سلسله مراتب استثناها، ترتیب گرفتن استثناها و کاربرد قدرتمند فیلترهای استثنا.
• اهمیت و نحوه ایجاد و پرتاب استثناهای سفارشی برای بیان خطاهای منطقی و تجاری خاص.
• مدیریت استثناهای کنترل‌نشده با استفاده از رویدادهای Global مانند AppDomain.CurrentDomain.UnhandledException برای لاگ‌نویسی در آخرین سنگر دفاعی.
• بهترین رویه‌ها و الگوهای طراحی، از جمله اصل "Fail Fast"، اجتناب از "Don't Catch 'Em All"، استفاده هوشمندانه از finally و using، طراحی API مناسب، و اهمیت throw; برای حفظ Stack Trace.
• ملاحظات عملکردی، توضیح اینکه چرا پرتاب استثنا گران است و چه زمانی نباید از آن برای کنترل جریان عادی برنامه استفاده کرد.
• و در نهایت، نقش حیاتی ثبت و پایش استثناها با استفاده از فریم‌ورک‌های لاگینگ و ابزارهای تجمیع و تحلیل لاگ، برای شناسایی و رفع مشکلات در محیط تولید.

نکات کلیدی برای به خاطر سپردن:

• استثناها برای شرایط استثنایی هستند: از آنها برای کنترل جریان عادی برنامه استفاده نکنید.
• استثناها را در لایه مناسب مدیریت کنید: در نقطه‌ای که می‌توانید منطق بازیابی معنی‌داری انجام دهید یا اطلاعات کافی را لاگ کنید.
• Stack Trace را حفظ کنید: همیشه از throw; (بدون آرگومان) برای پرتاب مجدد استثناها استفاده کنید.
• لاگ‌نویسی را جدی بگیرید: لاگ‌ها چشم و گوش شما در محیط تولید هستند. از فریم‌ورک‌های قدرتمند و لاگ‌های ساختاریافته استفاده کنید.
• استثناهای سفارشی را به درستی تعریف کنید: برای افزودن معنا و اطلاعات بیشتر به خطاهای دامنه تجاری خود.
• همیشه منابع را پاکسازی کنید: با استفاده از finally یا using.
• مدیریت خطا را تست‌پذیر کنید: سناریوهای خطا را در تست‌های واحد و یکپارچه‌سازی خود پوشش دهید.

با پیاده‌سازی یک استراتژی مدیریت خطای جامع و سیستماتیک، نه تنها برنامه‌هایی پایدارتر و مقاوم‌تر خواهید ساخت، بلکه فرآیند توسعه و نگهداری نرم‌افزار خود را نیز بهبود خواهید بخشید. این رویکرد، یک سرمایه‌گذاری برای آینده نرم‌افزار شماست که منجر به تجربه کاربری بهتر، کاهش زمان خرابی و تیم توسعه‌دهنده‌ای کارآمدتر خواهد شد.