अपवादों को पुनः प्राप्त करना

अपवाद हैंडलिंग तीन दशक पहले मुख्यधारा की प्रोग्रामिंग भाषाओं में दिखाई देती थी, लेकिन आज भी आप डेवलपर्स से मिल सकते हैं, जो उन्हें इस्तेमाल करने से डरते हैं। कुछ का मानना ​​है कि निर्माणकर्ता में अपवादों को फेंकने से उनके नाजुक कर्म को नुकसान होगा और वे पागल भारतीयों के झुंड द्वारा लिखे गए बीस साल पहले के कोड के समर्थन के रूप में सजा से आगे निकल जाएंगे। कुछ अभी भी सी भाषा के युग में फंसे हुए हैं, और यहां तक ​​कि सी # भाषा में वे जादुई संख्या या यहां तक ​​कि तार के रूप में रिटर्न कोड का गहनता से उपयोग करते हैं, यह मानते हुए कि कायर ने अपवादों का आविष्कार किया था, और वास्तविक समुराई उनके बिना कर सकते हैं। (यद्यपि आप और मैं जानते हैं कि वास्तविक समुराई "समुराई सिद्धांत" का पालन करते हैं और किसी भी रिटर्न कोड का उपयोग नहीं करते हैं)।

अतिरिक्त जटिलता विशिष्ट प्लेटफार्मों और प्रोग्रामिंग भाषाओं द्वारा जोड़ी गई है। आज C # डेवलपर इंटरव्यू में, जब अपवादों को संभालने की बात आती है, तो यह सवाल ज़रूर उठाया जाएगा: “ फेंक निर्माणों का उपयोग करके अपवादों को फेंकने में क्या अंतर है ; और पूर्व फेंक; ? ” और हालांकि यह एक भयानक बटन है और अधिकांश डेवलपर्स लंबे समय से इस सवाल का सही उत्तर जानते हैं, वास्तविक कोड में "गैर-कोषेर" संस्करण खोजना बहुत आसान है।

.NET प्लेटफ़ॉर्म की विशिष्ट विशेषता यह है कि यह मौजूद नहीं है (या बल्कि, जैसा कि हम जल्द ही देखेंगे - यह मौजूद नहीं था) एक स्थान पर अपवाद को पकड़ने और फिर इसे दूसरे में उत्पन्न करने का एक तरीका है। यदि किसी व्यवसाय एप्लिकेशन या लाइब्रेरी के डेवलपर को इस तरह की समस्या का सामना करना पड़ता है, तो इसे बहुत ही सरल तरीके से हल किया गया था: मूल अपवाद को एक नेस्टेड अपवाद के रूप में किसी अन्य ऑब्जेक्ट में लपेटा गया था और एक नया अपवाद फेंक दिया गया था।



आइए ऐसे एक उदाहरण को देखें। मान लें कि हमारे पास एक कस्टम अपवाद वर्ग है जिसे CustomException कहा जाता है, साथ ही एक साधारण वर्ग नमूनाक्लास , जिसका निर्माता इस अपवाद को फेंकता है।

//   ,  ,   class CustomException : Exception { } class SampleClass { //   , //     ,    public SampleClass() { throw new CustomException(); } } 

अब आइए जेनेरिक पद्धति का उपयोग करते हुए इस वर्ग की एक वस्तु बनाएं, और इस वर्ग का एक सिंगलटन भी बनाएं:

 //   ,    public static T CreateInstance<T>() where T : new() { return new T(); } //    class SampleClassSingleton { private static SampleClass _instance = new SampleClass(); static SampleClassSingleton() { } public static SampleClass Instance { get { return _instance; } } } 

सवाल यह है कि CreateInstance < SampleClass> () पद्धति को कॉल करते समय या SampleClassSingleton को एक्सेस करते समय कौन से कैच ब्लॉक को निष्पादित किया जाएगा । Instnace ?

 try { CreateInstance<SampleClass>(); //  var instance = SampleClassSingleton.Instance; } catch (CustomException e) { Console.WriteLine(e); } catch (Exception e) { Console.WriteLine(e); } 

मुझे नहीं लगता कि यह कोड किसी के लिए एक महान रहस्योद्घाटन होगा, लेकिन दोनों मामलों में "अपेक्षित" कैच ब्लॉक (CustomException e) को निष्पादित नहीं किया जाएगा, इसके बजाय कैच (अपवाद ई) ब्लॉक को निष्पादित किया जाएगा।

पहले मामले में (अर्थात, जब सामान्य CreateInstance विधि का उपयोग करते हुए), डिफ़ॉल्ट निर्माता को सीधे नहीं बुलाया जाता है, इसके बजाय, Activator.CreateInstance का उपयोग किया जाता है, जो मूल अपवाद को targetInvitException में लपेटता है। यही कारण है कि पकड़ (अपवाद ई) ब्लॉक को ट्रिगर किया जाता है, क्योंकि TargetInvocationException अपवाद हैंडलिंग के हमारे पहले ब्लॉक को फिट नहीं करता है।

चेतावनी
लॉग्स में केवल ई.मैसेज न लिखें, क्योंकि जब आपका प्रोडक्शन सर्वर लेट हो जाता है, तो यह जानकारी आपको न तो ठंडा और न ही गर्म बनाएगी, क्योंकि सबसे मूल्यवान जानकारी संलग्न अपवादों में से एक में दुबक सकती है। नेट फ्रेमवर्क के हिस्से के रूप में भी, कई स्थान हैं जो मूल अपवाद को लपेटते हैं और इसे एक नेस्टेड के रूप में फेंकते हैं, कस्टम कोड का उल्लेख नहीं करने के लिए जो एक दर्जन नेस्टेड लोगों में आपके द्वारा आवश्यक अपवाद को लपेट सकते हैं।

एक सिंगलटन का उपयोग करते समय, स्थिति समान होती है: चूंकि स्थिर निर्माण में _instance फ़ील्ड को आरंभीकृत किया जाता है, इसके निष्पादन के दौरान होने वाले कोई भी अपवाद प्रकार को "अमान्य" बनाते हैं। नतीजतन, इस प्रकार के सभी बाद के कॉल इसी नेस्टेड अपवाद के साथ टाइपऑलडैस्ट अपवाद को फेंक देंगे

नोट खाली स्थैतिक निर्माता की आवश्यकता क्यों है और इसकी अनुपस्थिति के कारण क्या समस्याएं हो सकती हैं, इस बारे में अधिक जानकारी के लिए, सिंगलटन और स्टैटिक कंस्ट्रक्टर के बारे में देखें ।

दोनों मामलों में व्यवहार अच्छी तरह से प्रलेखित और अच्छी तरह से जाना जाता है, इसलिए यदि एक बार इसे बग माना जा सकता है, तो अब यह एक विशेषता है। लेकिन, दुर्भाग्य से, हम इस स्थिति को ठीक नहीं कर सकते। यहां तक ​​कि अगर हम CreateInstance पद्धति में अपवाद को पकड़ते हैं और एक नेस्टेड अपवाद को फेंकने का प्रयास करते हैं, तो हम कॉल स्टैक खो देंगे, जिसके परिणामस्वरूप अपवाद बहुत कम उपयोगी होगा:

 public static T CreateInstance<T>() where T : new() { try { return new T(); } catch (TargetInvocationException e) { //    ,    ,   ! throw e.InnerException; } } 

इसी तरह की समस्या हमें इंतजार करती है अगर हम उदाहरण _ उदाहरण बनाते समय अपवाद को बचाने की कोशिश करते हैं और इंस्टेंस प्रॉपर्टी तक पहुंचने पर इसे फेंक देते हैं। (हाँ, विलंबित आरंभ इस विशेष समस्या को हल करेगा, लेकिन अब यह उस बारे में नहीं है)।

हालाँकि, .Net फ्रेमवर्क 4.5 में एक वर्ग दिखाई दिया है जो इस समस्या को हल करने में मदद कर सकता है। यह ExceptionDispatchInfo वर्ग है, जो मूल अपवाद को बचाने और कॉल स्टैक के बारे में जानकारी खोए बिना इसे फिर से फेंकने में सक्षम है। बेशक, इसके आवेदन का मुख्य बिंदु स्थिर कंस्ट्रक्टरों या एक्टिविटर के "स्ट्रेटनिंग" से संबंधित नहीं है। इसका मुख्य कार्य एसिंक्रोनस और मल्टीथ्रेडिंग के मुद्दों को हल करना है, जब एक अपवाद एक थ्रेड में होता है और दूसरे में फेंक दिया जाता है।

आइए निम्नलिखित कोड देखें:

 Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); }); try { int result = task.Result; } catch (CustomException e) { // ,      :( Console.WriteLine("CustomException caught: " + e); } catch (AggregateException e) { //      ! var inner = e.GetBaseException(); Console.WriteLine("Aggregate excpetion caught: " + inner); } 

यदि "कार्य" एक अपवाद के साथ विफल हो जाता है, तो मूल अपवाद (हमारे मामले में, CustomException ) को एक AggregateException में लपेटा जाएगा। इस व्यवहार के कई कारण हैं: पहला, हालांकि इसकी प्रकृति द्वारा कार्य एक एकल परिणाम के साथ कुछ लंबे अतुल्यकालिक ऑपरेशन पर एक खोल है, कुछ मामलों में एक कार्य का परिणाम कई कार्यों के समानांतर निष्पादन के परिणामों के आधार पर हो सकता है। उदाहरण के लिए, हम टास्क का उपयोग करके कई कार्यों को एक में जोड़ सकते हैं । WaitAll या हम निरंतरता का उपयोग करके कई कार्यों को बांध सकते हैं। इस व्यवहार का दूसरा कारण इसके कॉल स्टैक को विकृत किए बिना प्रारंभिक अपवाद को अग्रेषित करने में असमर्थता है।

हालांकि, अतुल्यकालिक के साथ काम करने के लिए सी # 5.0 में नई सुविधाओं के आगमन के बाद, प्राथमिकताएं कुछ हद तक बदल गईं। प्रतीक्षित और async कीवर्ड की मुख्य विशेषताओं में से एक तुल्यकालिक कोड को एसिंक्रोनस में परिवर्तित करने की सादगी है, लेकिन निष्पादन थ्रेड को "सीधा" करने के अलावा (जो कि कार्यों को वांछित होने पर भी छोड़ दिया जाता है), आयनों को संभालने का कार्य हल किया जाना चाहिए। इसलिए, जब प्रतीक्षित कीवर्ड का उपयोग करके किसी कार्य का परिणाम प्राप्त होता है, तो मूल AggregateException को फेंक दिया जाता है और मूल अपवाद को फेंक दिया जाता है:

 public static async void SimpleTask() { Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); }); try { // await «»      //    ,   AggregateExcpetion! int result = await task; } catch (CustomException e) { //    ,       Console.WriteLine("CustomException caught: " + e); } } 

नोट
यदि आप C # 5.0 भाषा की सुविधाओं जैसे कि Async और प्रतीक्षा से परिचित नहीं हैं, तो आप इस अंतर को लेख की मदद से भर सकते हैं: C # 5 में अतुल्यकालिक संचालन

जैसा कि पहले ही उल्लेख किया गया है, यह व्यवहार नए ExceptionDispatchInfo वर्ग का उपयोग करके लागू किया गया है, जो आपको मूल अपवाद को बचाने और बाद में फेंकने की अनुमति देता है, संभवतः एक नए धागे में भी। इसके अलावा, इसे इतनी सरलता से लागू किया गया है कि हमारे लिए अपने दम पर ऐसा करना मुश्किल नहीं होगा।

शुरू करने के लिए, चलिए T ask < T > क्लास के लिए एक क्लास बनाते हैं, जिसमें GetResult एक्सटेंशन मेथड होगा, जो कि रिजल्ट प्रॉपर्टी से काफी मिलता-जुलता होगा, लेकिन एग्रीगेटएक्सिटैशन को "स्ट्रेट" करेगा और कॉल स्टैक खोए बिना नेस्टेड अपवाद को फेंक देगा।

नोट
यह व्यवहार पहले से ही .net Framework 4.5 के भाग के रूप में कार्य < T > का उपयोग करके लागू किया गया है । गेटवाटर ()। GetResult () , लेकिन चलो इसके बारे में भूल जाते हैं और अपने दम पर ऐसा ही करते हैं।

ExceptionDispatchInfo वर्ग का उपयोग करना काफी सरल है: केवल स्थैतिक कैप्चर विधि का उपयोग करके एक स्थान पर अपवाद को पकड़ो, और फिर थ्रो विधि का उपयोग करके अपवाद को दूसरी जगह (और संभवतः एक अलग धागे में भी) फेंक दें ।

 static class TaskExtensions { public static T GetResult<T>(this Task<T> task) { try { T result = task.Result; return result; } catch (AggregateException e) { ExceptionDispatchInfo di = ExceptionDispatchInfo.Capture(e.InnerException); di.Throw(); return default(T); } } } 

अब, यदि आप पिछले कोड के टुकड़े को बदलते हैं और कार्य को प्रतिस्थापित करते हैं । टास्क विधि को कॉल करने पर परिणाम । GetResult , तो हम एक AggregateException के बजाय एक विशिष्ट प्रकार के अपवाद को पकड़ने में सक्षम होंगे।

 Task<int> task = Task<int>.Factory.StartNew(() => { throw new CustomException(); }); try { int result = task.GetResult(); } catch (CustomException e) { //     CustomException,   AggregateException Console.WriteLine("CustomException caught: " + e); } 

इसी प्रकार, आप हमारी CreateInstance पद्धति को बदल सकते हैं, जो TargetInfocationException को पकड़ लेगी और एक नेस्टेड अपवाद को फेंक देगी:

 public static T CreateInstance<T>() where T : new() { try { var t = new T(); return t; } catch (TargetInvocationException e) { //     ExceptionDispatchInfo ExceptionDispatchInfo di = ExceptionDispatchInfo.Capture(e.InnerException); //        di.Throw(); //   ,  di.Throws()   ,  //        ,     //   return default(T); } } 

अब, जब हम मुख्य कार्य से इस विधि को कॉल करने का प्रयास करते हैं, तो हमें एक सामान्य निष्पादन स्टैक के साथ एक समझदार अपवाद मिलता है:

ConsoleApplication1.CustomException: Exception of type 'ConsoleApplication1.CustomException' was thrown.<br>at ConsoleApplication1.SampleClass..ctor() in <br>c:\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 19<br> --- End of stack trace from previous location where exception was thrown ---<br> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()<br>at ConsoleApplication1.Program.CreateInstance[T]() in c<br>\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:<br>line 50<br>at ConsoleApplication1.Program.Main(String[] args) in c:\ \Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 63


एकल वर्ग को इस तरह से लागू किया जा सकता है।

ExceptionDispatchInfo वर्ग .Net फ्रेमवर्क के नए संस्करण की एक हत्यारा सुविधा होने की संभावना नहीं है, लेकिन एसिंक्रोनसी के युग के आगमन के साथ, यह निश्चित रूप से एक योग्य गुंजाइश ढूंढ लेगा। इसलिए, उदाहरण के लिए, यह पहले से ही प्रतीक्षित पैटर्न को लागू करने के लिए प्रतिक्रियाशील एक्सटेंशन की लाइब्रेरी में उपयोग किया जाता है (यह कार्यान्वयन केवल प्रयोगात्मक रिलीज में उपलब्ध है) और इसका उपयोग कोई भी व्यक्ति कर सकता है जो इस पैटर्न को अपने दम पर लागू करना चाहता है।