C# में त्रुटि प्रबंधन: try/catch और उन्नत तकनीकें

C# में त्रुटि प्रबंधन: try/catch से पेशेवर तकनीकों तक

C# और .NET पर औद्योगिक विकास की दुनिया में, त्रुटि प्रबंधन केवल try/catch संरचना नहीं है। यह एक संपूर्ण दर्शन है जो आपके कोड की विश्वसनीयता, पठनीयता और दोष-सहनशीलता को परिभाषित करता है। उन्नत स्तर पर, डेवलपर को न केवल अपवादों को पकड़ना चाहिए, बल्कि उन्हें कुशलतापूर्वक डिज़ाइन करना, फ़िल्टर करना, लॉग करना और एप्लिकेशन की स्थिति को पुनर्स्थापित करना भी आना चाहिए। इस लेख में, हम C# में त्रुटि प्रबंधन के प्रमुख पहलुओं पर चर्चा करेंगे जो आपको अधिक गुणवत्तापूर्ण और पेशेवर कोड लिखने में मदद करेंगे।

1. try/catch/finally में गहराई: संसाधन और संदर्भ प्रबंधन

मूल try-catch-finally संरचना सभी को ज्ञात है, लेकिन आइए इसे एक अलग कोण से देखें। finally ब्लॉक का मुख्य उद्देश्य संसाधनों की गारंटीकृत मुक्ति है, भले ही कोई अपवाद हुआ हो। C# के आधुनिक संस्करणों में, इसके लिए अक्सर using का उपयोग किया जाता है, लेकिन finally अप्रबंधित संसाधनों या जटिल समाप्ति तर्क के साथ काम करते समय अपरिहार्य रहता है।

public void ProcessFile(string path){    FileStream? fileStream = null;    try    {        fileStream = File.OpenRead(path);        // फ़ाइल प्रसंस्करण तर्क    }    catch (FileNotFoundException ex)    {        // विशिष्ट प्रबंधन: फ़ाइल नहीं मिली        Log.Error($"फ़ाइल {path} नहीं मिली: {ex.Message}");        throw; // कॉल स्टैक को संरक्षित करते हुए अपवाद को आगे भेजें    }    catch (UnauthorizedAccessException)    {        Log.Warn($"फ़ाइल तक पहुंच नहीं: {path}");        // अपवाद को आगे भेजे बिना वैकल्पिक कार्रवाई कर सकते हैं        return;    }    finally    {        // संसाधन की गारंटीकृत मुक्ति        fileStream?.Dispose();    }}

throw; (बिना तर्क के) के उपयोग पर ध्यान दें - यह एक महत्वपूर्ण बिंदु है। throw ex; के विपरीत, throw; संरचना मूल कॉल स्टैक को संरक्षित करती है, जो डिबगिंग के लिए महत्वपूर्ण है। वास्तविक परियोजनाओं में कभी भी throw ex; का उपयोग न करें, क्योंकि यह मूल त्रुटि के स्थान की जानकारी को नष्ट कर देता है।

2. उपयोगकर्ता-परिभाषित अपवाद: त्रुटियों का डोमेन मॉडल डिज़ाइन करना

बड़े एप्लिकेशन में, .NET के मानक अपवाद अक्सर पर्याप्त नहीं होते हैं। स्वयं के अपवाद वर्ग बनाने से त्रुटि के संदर्भ को सटीक रूप से व्यक्त किया जा सकता है और उच्च स्तरों पर प्रबंधन को सरल बनाया जा सकता है। एक अच्छे उपयोगकर्ता-परिभाषित अपवाद को सीरियलाइज़ेबल होना चाहिए, इसमें सार्थक संदेश होना चाहिए, और अतिरिक्त जानकारी (जैसे, इकाई पहचानकर्ता) शामिल होनी चाहिए।

[Serializable]public class OrderProcessingException : Exception{    public int OrderId { get; }    public string FaultyStep { get; }

    public OrderProcessingException(int orderId, string faultyStep, string message)         : base(message)    {        OrderId = orderId;        FaultyStep = faultyStep;    }

    public OrderProcessingException(int orderId, string faultyStep, string message, Exception inner)         : base(message, inner)    {        OrderId = orderId;        FaultyStep = faultyStep;    }

    // डीसीरियलाइज़ेशन के लिए कंस्ट्रक्टर    protected OrderProcessingException(        System.Runtime.Serialization.SerializationInfo info,        System.Runtime.Serialization.StreamingContext context) : base(info, context)    {        OrderId = info.GetInt32(nameof(OrderId));        FaultyStep = info.GetString(nameof(FaultyStep)) ?? string.Empty;    }

    public override void GetObjectData(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context)    {        base.GetObjectData(info, context);        info.AddValue(nameof(OrderId), OrderId);        info.AddValue(nameof(FaultyStep), FaultyStep);    }}

// उपयोगpublic void ValidateOrder(int orderId){    try    {