Kotlin / Java एरर हैंडलिंग: इसे सही कैसे करें?

स्रोत

किसी भी विकास में त्रुटि से निपटने में महत्वपूर्ण भूमिका होती है। कार्यक्रम में लगभग सब कुछ गलत हो सकता है: उपयोगकर्ता गलत डेटा दर्ज करेगा, या वे http के माध्यम से ऐसे आ सकते हैं, या हमने क्रमांकन / deserialization लिखते समय गलती की और प्रसंस्करण के दौरान प्रोग्राम एक त्रुटि के साथ क्रैश हो जाता है। हां, यह डिस्क स्थान से बाहर निकलकर कॉर्नी हो सकता है।

प्रस्तावना

दुर्भाग्य से (या ऐसा ही एक जीवन?), यह सूची आगे बढ़ती है। डेवलपर को लगातार इस तथ्य के बारे में सोचने की जरूरत है कि कहीं एक त्रुटि हो सकती है, और 2 स्थितियां हैं:

• जब अपेक्षित त्रुटि उस फ़ंक्शन को कॉल करने में होती है जिसे हमने प्रदान किया है और प्रक्रिया करने का प्रयास कर सकता है;
• जब एक अप्रत्याशित त्रुटि ऑपरेशन के दौरान होती है जिसे हमने पूर्वाभास नहीं किया था।

और अगर अपेक्षित त्रुटियां कम से कम स्थानीयकृत हैं, तो बाकी लगभग हर जगह हो सकती हैं। यदि हम कुछ भी महत्वपूर्ण प्रक्रिया नहीं करते हैं, तो हम बस एक त्रुटि के साथ क्रैश कर सकते हैं (हालांकि यह व्यवहार पर्याप्त नहीं है और आपको कम से कम त्रुटि लॉग में एक संदेश जोड़ने की आवश्यकता है)। लेकिन अगर अभी भुगतान की प्रक्रिया हो रही है और आप अभी नहीं गिर सकते हैं, लेकिन कम से कम आपको असफल ऑपरेशन के बारे में प्रतिक्रिया देने की आवश्यकता है?

इससे पहले कि हम त्रुटियों को संभालने के तरीके देखें, अपवाद (अपवाद) के बारे में कुछ शब्द:

अपवाद

स्रोत

अपवादों का पदानुक्रम अच्छी तरह से वर्णित है और आप इसके बारे में बहुत सारी जानकारी पा सकते हैं, इसलिए इसे यहाँ चित्रित करने का कोई मतलब नहीं है। अभी भी कभी-कभी गर्म चर्चा का कारण बनता है checked और unchecked त्रुटियों। और यद्यपि बहुमत ने unchecked अपवादों को प्राथमिकता के रूप में स्वीकार किया (कोटलिन में कोई भी अपवाद नहीं हैं), हर कोई इससे सहमत नहीं है।

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

आइए एक उदाहरण देखें। मान लें कि हमारे पास एक method फ़ंक्शन है जो एक चेक किए गए PanicException को फेंक सकता है। इस तरह के एक समारोह इस तरह दिखेगा:

 public void method() throws PanicException { } 

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

चेक किए गए अपवादों की आवश्यकता विनिर्देश द्वारा होती है, कि सभी संभावित चेक किए गए अपवाद (या उनके लिए एक सामान्य पूर्वज) फ़ंक्शन हस्ताक्षर में सूचीबद्ध हैं। इसलिए, अगर हमारे पास कॉल की एक श्रृंखला a -> b -> c और सबसे नेस्टेड फ़ंक्शन किसी तरह का अपवाद फेंकता है, तो इसे श्रृंखला में सभी के लिए नीचे रखा जाना चाहिए। और अगर कई अपवाद हैं, तो हस्ताक्षर में सबसे ऊपरी कार्य में उन सभी का विवरण होना चाहिए।

इसलिए, जैसा कि कार्यक्रम अधिक जटिल हो जाता है, यह दृष्टिकोण इस तथ्य की ओर जाता है कि शीर्ष समारोह में अपवाद धीरे-धीरे आम पूर्वजों के लिए ढह जाते हैं और अंत में Exception आते हैं। इस रूप में क्या एक unchecked अपवाद के समान हो जाता है और unchecked अपवादों के सभी लाभों को नकार देता है।

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

लेकिन अंतिम और संभवत: जावा से चेक किए गए अपवादों में सबसे बड़ा कील "चलाई" लंबोदा है। उनके हस्ताक्षर में कोई भी जांच अपवाद नहीं हैं except_ (ツ) _ / since (चूंकि किसी भी फ़ंक्शन को लंबोदर में कहा जा सकता है, किसी भी हस्ताक्षर), इसलिए लंबोदर से एक चेक अपवाद के साथ कोई भी फ़ंक्शन कॉल अनियंत्रित के रूप में अग्रेषित करने वाले अपवाद में लिपटे जाने के लिए मजबूर करता है:

 Stream.of(1,2,3).forEach(item -> { try { functionWithCheckedException(); } catch (Exception e) { throw new RuntimeException("rethrow", e); } }); 

सौभाग्य से, जेवीएम विनिर्देश में कोई भी अपवाद नहीं हैं, इसलिए कोटलिन में आप एक ही लैम्ब्डा में कुछ भी नहीं लपेट सकते हैं, लेकिन बस वांछित फ़ंक्शन को कॉल कर सकते हैं।

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

हैंडलिंग में त्रुटि

"अनपेक्षित" त्रुटियों के साथ मुख्य बात यह है कि एक जगह मिल जाए जहां आप उन्हें रोक सकें। JVM भाषाओं में, यह या तो एक स्ट्रीम क्रिएशन पॉइंट हो सकता है या http विधि के लिए एक फ़िल्टर / एंट्री पॉइंट, जहाँ आप unchecked त्रुटियों से निपटने की कोशिश कर सकते हैं। यदि आप किसी भी ढांचे का उपयोग करते हैं, तो सबसे अधिक संभावना है कि इसमें पहले से ही सामान्य त्रुटि हैंडलर बनाने की क्षमता है, उदाहरण के लिए, स्प्रिंग फ्रेमवर्क में, आप @ExceptionHandler एनोटेशन के साथ विधियों का उपयोग कर सकते हैं।

आप इन केंद्रीय प्रसंस्करण बिंदुओं के अपवादों को "बढ़ा सकते हैं", जिन्हें हम एक ही unckecked अपवादों को फेंककर विशिष्ट स्थानों में संभालना नहीं चाहते हैं (जब, उदाहरण के लिए, हम नहीं जानते कि किसी विशेष स्थान पर क्या करना है और त्रुटि को कैसे संभालना है)। लेकिन यह विधि हमेशा उपयुक्त नहीं है, क्योंकि कभी-कभी इसमें त्रुटि को संभालने की आवश्यकता हो सकती है, और आपको यह जांचने की आवश्यकता है कि फ़ंक्शन कॉल के सभी स्थानों को सही तरीके से संसाधित किया गया है। ऐसा करने के तरीकों पर विचार करें।

1. अभी भी अपवाद और एक ही कोशिश-कैच का उपयोग करें:

   
   

     int a = 10; int b = 20; int sum; try { sum = calculateSum(a,b); } catch (Exception e) { sum = -1; } 

   
   

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

   
   

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

   
   

    sealed class Result data class SuccessResult(val value: Int): Result() data class ExceptionResult(val exception: Exception): Result() val a = 10 val b = 20 val sum = when (val result = calculateSum(a,b)) { is SuccessResult -> result.value is ExceptionResult -> { result.exception.printStackTrace() -1 } } 

   
   

   जब हम परिणामी मूल्यों (या स्पष्ट रूप से अनदेखी) की स्पष्ट रूप से जांच करने की आवश्यकता होती है, तो हमें एक golang त्रुटि दृष्टिकोण जैसा कुछ मिलता है। दृष्टिकोण काफी व्यावहारिक है और विशेष रूप से सुविधाजनक है जब आपको प्रत्येक स्थिति में बहुत सारे मापदंडों को फेंकने की आवश्यकता होती है। Result वर्ग को विभिन्न तरीकों से विस्तारित किया जा सकता है जो उपरोक्त अपवाद के साथ परिणाम प्राप्त करना आसान बनाते हैं, यदि कोई हो (यदि हमें कॉल की जगह पर त्रुटि को संभालने की आवश्यकता नहीं है)। मुख्य दोष केवल मध्यवर्ती सतही वस्तुओं (और थोड़ी अधिक वर्बोज़ प्रविष्टि) का निर्माण होगा, लेकिन इसे inline कक्षाओं (यदि एक तर्क हमारे लिए पर्याप्त है) का उपयोग करके हटाया जा सकता है। और, एक विशेष उदाहरण के रूप में, कोटलिन का एक Result वर्ग है। सच है, यह केवल आंतरिक उपयोग के लिए है, जैसा कि भविष्य में, इसका कार्यान्वयन थोड़ा बदल सकता है, लेकिन यदि आप इसका उपयोग करना चाहते हैं, तो आप संकलन ध्वज को जोड़ सकते हैं -Xallow-result-return-type ।

   
   

3. दावा 2 के संभावित प्रकारों में से एक के रूप में, Either कार्यात्मक प्रोग्रामिंग से प्रकार का उपयोग, जो या तो एक परिणाम या एक त्रुटि हो सकती है। प्रकार स्वयं एक sealed वर्ग या एक inline वर्ग हो सकता है। नीचे arrow पुस्तकालय से कार्यान्वयन का उपयोग करने का एक उदाहरण है:

   
   

    val a = 10 val b = 20 val value = when(val result = calculateSum(a,b)) { is Either.Left -> { result.a.printStackTrace() -1 } is Either.Right -> result.b } 

   
   

   Either उन लोगों के लिए सबसे उपयुक्त है जो एक कार्यात्मक दृष्टिकोण से प्यार करते हैं और जो कॉल चेन का निर्माण करना पसंद करते हैं।

   
   

4. कोटलिन से Option या nullable प्रकार का उपयोग करें:

   
   

    fun testFun() { val a = 10 val b = 20 val sum = calculateSum(a,b) ?: throw RuntimeException("some exception") } fun calculateSum(a: Int, b: Int): Int? 

   
   

   यह दृष्टिकोण उपयुक्त है यदि त्रुटि का कारण बहुत महत्वपूर्ण नहीं है और जब यह केवल एक है। एक खाली उत्तर को एक त्रुटि माना जाता है और इसे अधिक फेंक दिया जाता है। सबसे कम रिकॉर्ड, अतिरिक्त ऑब्जेक्ट्स बनाए बिना, लेकिन यह दृष्टिकोण हमेशा लागू नहीं किया जा सकता है।

   
   

5. आइटम 4 के समान, केवल एक त्रुटि मार्कर के रूप में एक हार्डकोड मान का उपयोग करता है:

   
   

    fun testFun() { val a = 10 val b = 20 val sum = calculateSum(a,b) if (sum == -1) { throw RuntimeException(“error”) } } fun calculateSum(a: Int, b: Int): Int 

   
   

   यह संभवतः सबसे पुराना त्रुटि हैंडलिंग दृष्टिकोण है जो C (या अल्गोल से भी) में वापस आया था। ओवरहेड नहीं है, केवल एक कोड जो पूरी तरह से स्पष्ट नहीं है (परिणाम की पसंद पर प्रतिबंध के साथ), लेकिन, चरण 4 के विपरीत, एक से अधिक संभावित अपवाद की आवश्यकता होने पर विभिन्न त्रुटि कोड बनाना संभव है।

   
   

निष्कर्ष

सभी दृष्टिकोणों को स्थिति के आधार पर जोड़ा जा सकता है, और उनमें से कोई भी ऐसा नहीं है जो सभी मामलों में उपयुक्त हो।

इसलिए, उदाहरण के लिए, आप sealed कक्षाओं का उपयोग करके त्रुटियों के लिए एक golang दृष्टिकोण प्राप्त कर सकते हैं, और जहां यह बहुत सुविधाजनक नहीं है, unchecked त्रुटियों पर आगे बढ़ें।

या, अधिकांश स्थानों पर, एक मार्कर के रूप में nullable प्रकार का nullable कि मूल्य की गणना करना या कहीं से प्राप्त करना संभव नहीं था (उदाहरण के लिए, एक संकेतक के रूप में कि डेटाबेस में मूल्य नहीं मिला था)।

और अगर आपके पास arrow या कुछ इसी तरह की लाइब्रेरी के साथ पूरी तरह कार्यात्मक कोड है, तो यह सबसे अच्छी तरह से Either उपयोग करने की संभावना है।

Http- सर्वर के लिए, केंद्रीय बिंदुओं के लिए सभी त्रुटियों को उठाना सबसे आसान है और केवल कुछ स्थानों पर sealed वर्गों के साथ nullable दृष्टिकोण को जोड़ते हैं।

मुझे टिप्पणियों में यह देखकर खुशी होगी कि आप इसका उपयोग कर रहे हैं, या शायद अन्य सुविधाजनक त्रुटि से निपटने के तरीके हैं?

और अंत तक पढ़ने वाले सभी को धन्यवाद!