सभी में से, मैं सोच रहा था कि क्या किसी को पता था कि अपवादों के बीच अंतर क्या था (अपवाद नियंत्रण प्रवाह के दायरे में) और अपवाद (जैसे जावा में उपयोग किया गया)।
लेकिन क्या वे मूल रूप से उपयोगकर्ता प्रोग्राम को समाप्त करके सिस्टम को क्रैश होने से बचा सकते हैं?
जवाबों:
अपवाद अपवाद को संभालने के लिए मौजूद हैं , जो दुर्घटनाओं से बच सकते हैं, लेकिन आमतौर पर अवांछित या अप्रत्याशित सिस्टम व्यवहार को रोक सकते हैं। उदाहरण के लिए अगर मेरे प्रोग्राम का डेटाबेस से कनेक्शन बार-बार होता है, तो यह आमतौर पर सिस्टम को क्रैश करने वाला नहीं होता है, लेकिन अगर मैं डेटाबेस के डेटा पर निर्भर था, तो एक अपवाद मुझे इस डेटा-कम स्थिति का इलाज करने की अनुमति दे सकता है जो सामान्य से अलग है।
डिफ़ॉल्ट रूप से कहें तो मेरा प्रोग्राम डेटा का एक पृष्ठ प्रदर्शित करता है जो डेटाबेस से लौटाया गया है - ठीक है, मेरे पास कोई डेटा नहीं है। एक गड़बड़ दृश्य प्रस्तुत करने या संभावित अवैध संचालन जारी रखने के बजाय मैं इस अपवाद को पकड़ सकता हूं और एक अलग डेटाबेस में वापस आ सकता हूं, स्थानीय डेटा से पढ़ा जा सकता है, उपयोगकर्ता से डेटा मांग सकता है या अन्यथा उपयोगकर्ता या सिस्टम को एक सुरक्षित स्थिति में लौटा सकता है (संभवतः एक कि तुरंत एक ही अपवाद का कारण नहीं होगा! "
उन प्रणालियों में जहां उपयोगकर्ता इनपुट समस्या का कारण / समाधान हो सकता है, अपवाद किसी उपयोगकर्ता को समस्या के बारे में विस्तृत और उपयोगी जानकारी दे सकते हैं। बहुत सामान्य के बजाय "एक बिना अपवाद अपवाद हुआ ..." या "SQL से सीधे त्रुटि संदेश को धमकाना" आप उपयोगकर्ता को कुछ सहायक या कम से कम समझने योग्य बता सकते हैं जैसे "संसाधन बी से कनेक्ट नहीं कर सका।"
त्रुटि-हैंडलिंग को सरल बनाने के लिए अपवाद बनाए गए थे। अपवादों के बिना, त्रुटि से निपटने वाले तर्क को एक आवेदन में फैलाया जाना चाहिए। कोई भी फ़ंक्शन जो संभवतः त्रुटि का परिणाम हो सकता है, किसी तरह एक त्रुटि स्थिति वापस करना चाहिए, और प्रत्येक कॉल के लिए त्रुटि की जांच होनी चाहिए। अक्सर कॉलर त्रुटि के मामले में कुछ भी उपयोगी नहीं कर सकता है, और केवल एक त्रुटि ही वापस कर सकता है। आधा आवेदन कोड त्रुटि से निपटने के लिए समर्पित हो सकता है। ऐसा कोड बेहद नाजुक होता है। किसी त्रुटि की जाँच और दुर्घटना को छोड़ना, या इससे भी बदतर, किसी अनजान त्रुटि के कारण गलत परिणाम लौटना सब बहुत आसान है।
अपवादों के साथ, त्रुटियों को केवल उस बिंदु पर जांचा जा सकता है जहां उन्हें संभाला जा सकता है। अधिकांश एप्लिकेशन कोड स्ट्रेट-लाइन फ़ैशन में लिखे जा सकते हैं, क्योंकि फ़ंक्शंस या तो उपयोग करने योग्य मूल्य वापस कर देंगे या अपवाद फेंक देंगे।
असाधारण परिस्थितियों के उपयोगकर्ता को सूचित करने के लिए एक अपवाद का बिंदु होना चाहिए। यदि सिस्टम में कुछ गड़बड़ हो जाती है, तो प्रोग्राम को पता होना चाहिए और इसे उचित रूप से संभालने की अनुमति दी जानी चाहिए।
उस ने कहा, नहीं, सिस्टम को "क्रैश" से रोकने के लिए कोई अपवाद मौजूद नहीं है। एक अपवाद यह मुझे बता रहा है कि एक समस्या है। मैं कैसे निर्धारित करता हूं कि क्या सिस्टम "क्रैश" निर्धारित कर सकता है।
यह भी ध्यान दें कि एक अपवाद के लिए एक आवेदन को समाप्त करने की आवश्यकता नहीं है जैसा आपने कहा है। एक अपवाद को प्रोग्रामर द्वारा नियंत्रित किया जा सकता है और इसे उपयोगकर्ता के लिए कुछ सार्थक त्रुटि के रूप में सुधारा या बदल दिया जाता है।
* जाँच किए गए अपवादों (अपवादों को पकड़े जाने के लिए मजबूर किया जाता है) का उपयोग एक व्यथा का एक सा है। कुछ (शायद सबसे) डेवलपर्स पाते हैं कि मजबूर अपवाद हैंडलिंग बोझिल, अनावश्यक, और सिर्फ बुरा अभ्यास है।
अपवाद त्रुटि हैंडलर से त्रुटि स्थान को विभाजित करके आधुनिक त्रुटि हैंडलिंग की अनुमति देते हैं। कभी-कभी इसका उपयोग प्रवाह नियंत्रण के लिए भी किया जाता है।
बिना किसी अपवाद के किसी प्रोग्राम को समाप्त कर दें। लेकिन ये पूर्व अपवादों से अलग नहीं हैं, बस एक आलसी प्रोग्रामर जो हर रास्ते में उचित त्रुटि संचालकों को शामिल करना भूल गया, उन्हें अंतिम उपयोगकर्ता के लिए दृश्यमान बनाता है। मैं अपवाद के रूप में किसी भी अन्य अप्रत्याशित अंत के रूप में दुर्घटनाग्रस्त द्वारा समाप्त किए गए कार्यक्रम पर विचार करता हूं।
OSes बहुत अच्छी तरह से क्रैश किए गए प्रक्रियाओं की सफाई करते हैं, चाहे वे दुर्घटनाग्रस्त क्यों न हों, इसलिए अपवाद OS की सुरक्षा को किसी अन्य तरीके से खराबी प्रक्रियाओं को समाप्त करने और अपने संसाधनों को जारी करने से जोड़ते नहीं हैं।
यह बहुत सरल है।
अपवादों का आविष्कार होने से पहले, प्रत्येक फ़ंक्शन को एक एक्जिट कोड (त्रुटि / सफलता) वापस करना पड़ता था और फ़ंक्शन के किसी भी परिणाम या आउटपुट को इसके द्वारा सेट की जाने वाली मेमोरी के लिए एक पॉइंटर पास करके पुनः प्राप्त करना पड़ता था।
समस्या यह थी कि कई प्रोग्रामर को याद नहीं था / हर एक फंक्शन के लिए गलत एग्जिट कोड की जांच करने की जहमत नहीं उठाते थे, और इसलिए कभी-कभी घातक व्यवहार को भी अनदेखा कर दिया जाता था, जिससे काफी अस्पष्ट व्यवहार होते थे।
इसलिए, यह तय किया गया था - जब एक त्रुटि होती है, जिसे आपने ध्यान में नहीं लिया, तुरंत दुर्घटना! AKA अपवाद हैंडलिंग।
अपवाद केवल एक त्रुटि पहचान तंत्र हैं। अपने आप से उनका कोई मतलब नहीं है।
लेकिन एक त्रुटि का पता लगाकर, वे त्रुटिपूर्ण स्थिति से एक त्रुटि-मुक्त स्थिति (एक पिछली स्थिति या एक नया) पर स्विच करके पुनर्प्राप्त करने के लिए गलती सहिष्णुता तंत्र को ट्रिगर करने की अनुमति देते हैं। इस तरह, सिस्टम के अन्य हिस्सों में त्रुटि का प्रसार नहीं होता है।
त्रुटि हैंडलिंग प्रवाह (कैसे प्रोग्राम एक असाधारण स्थिति से उबरने की कोशिश कर रहा है) से सामान्य कार्यक्रम प्रवाह (कार्यक्रम को करने के लिए डिज़ाइन किया गया) को अलग करने के लिए मौजूद है ।
यह कोड को अधिक स्पष्ट और बनाए रखने में आसान बनाता है।
दो संहिताओं पर विचार करें:
try:
do1() # this is obvoiusly a normal
do2() # program flow
except:
oups() # this is exception handling code
इसकी तुलना में:
if foo():
thing1() # is this part of normal program flow?
else:
thing2() # or maybe this one? Or both? When?
बेशक, अपवाद हैंडलिंग प्रोग्राम को दुर्घटनाग्रस्त होने से बचाने के लिए उपयोग किया जा सकता है:
try { // very bad code
my();
whole();
ugly();
application();
here();
} catch (Throwable t) {
// pretend it's ok
}
लेकिन यह आधुनिक प्रोग्रामिंग भाषाओं में अपवादों का कारण नहीं है।
तुम भी उपयोग कर सकते हैं whileऔर breakके बजाय if, लेकिन यह नहीं है क्या whileऔर breakके लिए कर रहे हैं।