अपवाद! = त्रुटि

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

जब php5 अपवादों के साथ दिखाई दिया, और फिर ZendFramework, जो हमेशा अपवादों को फेंकता है, तो मैं समझ नहीं पाया: मेरे पसंदीदा ट्रिगर_रोर () से बेहतर अपवाद क्यों है? मैंने लंबे समय तक सोचा, सहयोगियों के साथ चर्चा की और इस मुद्दे का पता लगाया। अब मुझे स्पष्ट रूप से पता है कि कहाँ ट्रिगर_रोर () का उपयोग करना है, और कहाँ नया एक्सेप्शन फेंकना है।

दोनों के बीच मूलभूत अंतर क्या है?

त्रुटियों

त्रुटियां कुछ ऐसी होती हैं जिन्हें ठीक नहीं किया जा सकता, आप केवल इसे रिपोर्ट कर सकते हैं: लॉग में लिखें, डेवलपर को एक ईमेल भेजें और उपयोगकर्ता से माफी मांगें। उदाहरण के लिए, यदि मेरा इंजन डेटाबेस से कनेक्ट नहीं हो सकता है, तो यह एक त्रुटि है। वह सब है। बिंदु। साइट डेटाबेस के बिना काम नहीं करती है, और मैं इसके बारे में कुछ नहीं कर सकता। इसलिए, मैं ales_kaput () और trig_error () को कॉल करता हूं, और मेरी त्रुटिहैंडलर मुझे एक ईमेल भेजेगा और आगंतुक को "क्षमा करें, साइट नीचे है" संदेश दिखाएगा।

अपवाद

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

उनका मुख्य उद्देश्य: कैस्केड के साथ आगे बढ़ना है । मैं इसे एक उदाहरण के साथ दिखाऊंगा: तीन कार्य हैं जो कैस्केड में एक दूसरे को कहते हैं:

<?php a(); function a() { b(); } function b() { c(99); } function c($x) { if ($x === 0) { //   , //      c()  b(), //   a()     } return 100 / $x; } 

इस समस्या को अपवाद तंत्र के बिना हल किया जा सकता था। उदाहरण के लिए, आप सभी प्रकारों को एक विशेष प्रकार को लौटाने के लिए बाध्य कर सकते हैं (यदि आप एक अनुभवी पपाशनिक हैं, तो आपको PEAR_Error याद रखना चाहिए) । सादगी के लिए, मैं अशक्तता के साथ करूंगा:

 <?php a(); function a() { echo 'a-begin'; $result = b(); if ($result === null) { echo '   '; return; } echo 'a-stop'; } function b() { echo 'b-begin'; $result = c(0); if ($result === null) { return null; } echo 'b-stop'; return true; } function c($x) { echo 'c-begin'; if ($x === 0) { return null; } echo 'c-stop'; return 100 / $x; } 

काम का परिणाम:

एक-शुरू
बी-शुरू
सी शुरू
शून्य से भाग देना अच्छा नहीं है

कार्य पूरा हो गया है, लेकिन, ध्यान दें, मुझे मध्यवर्ती फ़ंक्शन बी () को संशोधित करना था ताकि यह झरना में अधीनस्थ फ़ंक्शन के काम के परिणाम को फेंकता है। और अगर मेरे पास 5 या 10 कार्यों का झरना है? फिर मुझे सभी मध्यवर्ती कार्यों को संशोधित करना होगा। और क्या होगा अगर अपवाद निर्माणकर्ता में है? कि मुझे बैसाखी को स्थान देना होगा।

और अब अपवाद का उपयोग कर समाधान:

 a(); function a() { echo 'a-begin'; try { b(); echo 'a-stop'; } catch (Exception $e) { echo $e->getMessage(); } } function b() { echo 'b-begin'; c(0); echo 'b-stop'; } function c($x) { echo 'c-begin'; if ($x === 0) { throw new Exception('   '); } echo 'c-stop'; return 100 / $x; } 

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

इस प्रकार, यह पता चला है कि त्रुटियों और अपवाद पूरी तरह से अलग-अलग समस्याओं को हल करने के लिए पूरी तरह से अलग उपकरण हैं:
एक त्रुटि एक अपूरणीय स्थिति है;
अपवाद - आपको कार्यों के कैस्केड को बाधित करने और कुछ जानकारी को अग्रेषित करने की अनुमति देता है। ग्लोबल रिटर्न स्टेटमेंट जैसा कुछ। यदि आपके पास कैस्केड नहीं है, तो आपको बस का उपयोग करने की आवश्यकता है यदि या वापस।

त्रुटियां हमेशा त्रुटियां नहीं होती हैं

कुछ को आपत्ति हो सकती है: “ज़ेंड फ्रेमवर्क में देखो - वे हमेशा अपवाद फेंकते हैं। ये सबसे अच्छे अभ्यास हैं, और किसी को भी करना चाहिए। यहां तक ​​कि अगर आप डेटाबेस से कनेक्ट नहीं कर पाए, तो भी आपको एक अपवाद फेंकने की जरूरत है। ”

इस लेख में, मैं सिर्फ इस गलत धारणा को दूर करना चाहता हूं। Zend वास्तव में सबसे अच्छा अभ्यास है, लेकिन Zend के प्रोग्रामर एक अलग नाव पर हैं और अन्य चीजें कर रहे हैं। उनके और मेरे बीच मूलभूत अंतर यह है कि वे एक सार्वभौमिक पुस्तकालय लिखते हैं जिसका उपयोग कई परियोजनाओं में किया जाएगा। और वे अपने घंटी टॉवर से यह नहीं कह सकते हैं कि एक महत्वपूर्ण गलती क्या है और क्या ठीक है।

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

नतीजतन, मैं कह सकता हूं कि दोनों तंत्रों की अपनी विशेषताएं हैं और सबसे महत्वपूर्ण बात यह है कि उनकी अपनी नियति है और ये गंतव्य बिल्कुल भी नहीं हैं। त्रुटियां! = अपवाद । प्रदर्शन या त्रुटि संदेशों को सुधारने के लिए अपवादों का उपयोग न करें। My_Custom_Exception वर्ग में किसी भी सुधार तर्क को लागू करना आवश्यक नहीं है। यह वर्ग खाली होना चाहिए, यह केवल स्थिति के प्रकार को निर्धारित करने और केवल उसी चीज़ को पकड़ने के लिए बनाया गया है जिसकी आवश्यकता है। वर्ग का नाम 'My_Custom_Exception' एक पेड़ की तरह है जो स्थिरांक की निरंतर सूची E _ *** (E_NOTICE, E_WARNING, ...) है।

PHP में, एक त्रुटि हैंडलिंग तंत्र लंबे समय से विकसित किया गया है, और यह बहुत अच्छा काम करता है। जहां जरूरत होती है मैं वहां इसका अच्छा इस्तेमाल करता हूं।