मैं जानना चाहता हूं, सामान्य प्रोग्रामिंग में बेहतर या/और तेज़ क्या है? अपवाद से बचें या अपवाद के लिए प्रतीक्षा करें?क्या बेहतर/तेज है? कोशिश करें या अपवाद से बचें?
बचें अपवाद होगा:
string a = null;
list = someMethod();
if(list.Length > 0){
a = list[0];
}
if(a!=null) ...
या पकड़ अपवाद कोशिश ...
string a = null;
try{
a = someMethod()[0];
catch{}
if(a!=null) ...
प्रदर्शन यहां सबसे अधिक प्रासंगिक चिंता नहीं है। सवाल यह है कि, दोनों में से कौन सा अधिक पठनीय/रखरखाव/परीक्षण योग्य कार्यक्रमों की ओर जाता है। आप बाद में प्रदर्शन के बारे में चिंता कर सकते हैं।
सामान्य रूप से, प्रवाह नियंत्रण के लिए अपवादों का उपयोग न करें। वे प्रभावी रूप से एक गैर-स्थानीय goto हैं जो प्रोग्राम को पढ़ने और अनुसरण करने में अधिक कठिन बनाता है। ऐसे में, उन्हें असाधारण परिस्थितियों के लिए आरक्षित किया जाना चाहिए। यदि आप प्रवाह नियंत्रण के लिए try-catch ब्लॉक का उपयोग न करने से दूर हो सकते हैं, तो नहीं। आपके कार्यक्रम अधिक पठनीय और रखरखाव योग्य होंगे।
"सही" जिस तरह से इस स्थिति से निपटने के
var list = someMethod();
if(list == null || list.Length == 0) {
// handle something bad
}
string a = list[0];
if(a != null) {
// go
}
आप जाँच लें कि list अशक्त और खाली नहीं नहीं है बच सकते हैं अगर वहाँ एक अनुबंध (Contract.Ensures) गारंटी देता है कि someMethod से वापसी मान है है शून्य नहीं और खाली नहीं है।
यह सच है, हालांकि, अपवाद स्थानीय रूप से महंगे हैं। चाहे वे आपके प्रोग्राम के प्रदर्शन को प्रभावित करेंगे या नहीं (यानी, एक बाधा है) एक और सवाल है। लेकिन सही ढंग से उपयोग किया जाता है, अपवाद आमतौर पर एक बाधा नहीं होती है (जो आपका एप्लिकेशन क्रैश होने पर प्रदर्शन की परवाह करता है?)
हाँ, उत्तर के लिए धन्यवाद, मुझे पता था कि कोशिश करने और खाली पकड़ के साथ कुछ सही नहीं था। कार्यक्रमों के बारे में अधिक रखरखाव बहुत सच है। हो सकता है कि एक और अपवाद अपेक्षित न हो और आप कभी नहीं जान पाएंगे। हो सकता है कि अगर आपको कोई परवाह नहीं है कि आप कौन सा अपवाद हो सकते हैं तो आप एक खाली पकड़ समझेंगे। – carlosdubusm
@carlosdumusm: आपको यह सही ढंग से समझने लगते हैं, लेकिन मैं यह इंगित करना चाहता हूं कि सभी अपवादों को पकड़ने वाले खाली 'पकड़' ब्लॉक या 'पकड़' ब्लॉक (यानी, बेस क्लास 'अपवाद' पकड़ें) खराब, खराब, खराब। आपको पता नहीं है कि किस प्रकार का अपवाद फेंक दिया जा सकता है लेकिन अब आप यह घोषणा कर रहे हैं कि आप उन सभी को संभाल सकते हैं।जब चीजें खराब स्थिति में होती हैं, लेकिन आप नहीं जानते कि कितना बुरा या बुरा राज्य क्या है क्योंकि आप सभी अपवादों को "संभालना" कर रहे हैं, तो यह जारी रखना बहुत खतरनाक है जैसे कुछ भी नहीं हुआ। जो आप जानते हैं उसे संभालें जिसे आप संभाल सकते हैं, और अन्यथा तेज़ी से विफल हो जाते हैं। – jason
हाँ, समझ में आता है, मेरे पास कई वर्षों का प्रोग्रामिंग है लेकिन मुझे अपवादों के बारे में बहुत कम ज्ञान है, और कभी-कभी नहीं पता कि कोशिश करने के लिए कहां या कहां फेंकना है। धन्यवाद। – carlosdubusm
हमेशा हमेशा हमेशा एक अपवाद से बचने यदि आप कर सकते हैं।
अपवाद असाधारण होना चाहिए।
यदि आप इसकी भविष्यवाणी कर सकते हैं, तो इसके खिलाफ सुरक्षा हो सकती है।
जो लोग इस तरह खाली पकड़ ब्लॉक का उपयोग एक कंप्यूटर का उपयोग करने से प्रतिबंधित किया जाना चाहिए ...
यह भी तेज है पकड़ ब्लॉक में जाना नहीं है।
अपवाद महंगे हैं - यदि आप अपवाद का परीक्षण और बचाव कर सकते हैं, तो ऐसा करें।
सामान्य कार्यक्रम प्रवाह के लिए अपवादों का उपयोग नहीं किया जाना चाहिए।
हाँ, अपवादों की लागत के बारे में कभी सोचा नहीं, धन्यवाद। – carlosdubusm
अपवाद फेंकना एक महंगा काम है, इसलिए मैं हमेशा पकड़ने की बजाय कोशिश करता हूं और मान्य करता हूं।
यह परीक्षण करने के लिए काफी आसान होना चाहिए, प्रत्येक कोड के माध्यम से अपवाद फेंकने वाले कुछ कोड उत्पन्न करें और कोड के समान सेट के खिलाफ परीक्षण करें जो सशर्त जांच और प्रदर्शन को मापता है।
यदि कोड के विवरण के साथ दस्तावेज दस्तावेज किया गया है, तो अपवादों को फेंक दिया जाएगा, तो आप अपने कॉलिंग कोड को अनुकूलित करने में सक्षम होना चाहिए। निस्संदेह आप प्रत्येक परिदृश्य (निचले स्तर की रनटाइम त्रुटियों को शायद?) को संभाल नहीं सकते हैं, इसलिए आपका कोड केवल उन प्रयासों को अपनाने और संभालने के लिए चाहिए जहां वास्तव में प्रतिक्रिया हो सकती है और संभवतः जारी रह सकती है।
यह निर्भर करता है। मैं हमेशा अपवाद से बचने की कोशिश करता हूं जब तक कि ऐसा करना महंगा नहीं है।
अपवादों का उपयोग केवल असाधारण परिस्थितियों के लिए किया जाना चाहिए (जब तक कि कोई विकल्प न हो), तो आपको केवल इतना ही असामान्य बात होनी चाहिए कि आपको अभी भी निपटने की आवश्यकता है (एक त्रुटि संदेश पॉप अप करें)।
एक प्रोग्रामर को कोशिश/पकड़ने के संकेत भी हैं कि कुछ बाहरी त्रुटि हो सकती है और इसके साथ निपटने की आवश्यकता है। आपके उदाहरण में, list शून्य होने के कारण प्रोग्राम निष्पादन/नियंत्रण प्रवाह का एक सामान्य हिस्सा है, और इसलिए इसके बारे में कुछ भी असाधारण नहीं है।
इसके अलावा, एक खाली पकड़-आम तौर पर वैसे भी एक बुरी चीज है (हालांकि सीमित परिस्थितियां हैं जहां इसकी आवश्यकता है)। यह निश्चित रूप से यह बताने के लिए एक टिप्पणी की ज़रूरत है कि आप अपवादों के बारे में कुछ क्यों नहीं कर रहे हैं।
वहाँ एक useful blog post अप्रिय अपवाद के बारे में आप एक महत्वपूर्ण एन क्रम से अधिक निर्देश/प्रदर्शन दृष्टिकोण के एक नंबर से
शुद्ध रूप से उपयोगी लग सकते, परहेज, और अधिक महंगा है, क्योंकि आप हर इनपुट के लिए लंबाई हर बार की जाँच कर रहे है । अपवाद के साथ, catch शाखा केवल उस घटना पर निष्पादित की जाती है।
लेकिन जब ऐसा होता है तो यह धीमा होता है। यह अन्य संभावित त्रुटियों को मुखौटा करता है। और यह भयानक प्रोग्रामिंग अभ्यास है। – CaffGeek
कोशिश-पकड़ सामान्य प्रवाह में कोई ओवरहेड नहीं लेता है? उदाहरण में उपयोग किए जाने वाले परीक्षण और कूद समय की प्रक्रिया के मामले में काफी सस्ते लगते हैं। – Derrick
यह एक भयानक प्रोग्रामिंग अभ्यास है जब यह खाली 'पकड़ {}' है, जैसा कि आपने कहा था, अन्य प्रोग्रामिंग त्रुटियों को मुखौटा करता है। और जैसा कि बताया गया है, असाधारण स्थितियों के लिए अपवादों का उपयोग किया जाना चाहिए, ऐसा कुछ नहीं जो नियमित रूप से होता है (उदाहरण के लिए यदि आप जानते हैं कि सूची हमेशा प्रारंभिक पर शून्य होगी और अक्सर इसे हिट करने की उम्मीद है, तो यह अब असाधारण नहीं है और आपको चेक में बनाना चाहिए इसके लिए)। – Aphex
बेशक अपवाद से बचें, पकड़ने का प्रयास करें हानि प्रदर्शन की ओर जाता है।
"तेज़" शब्द को रद्द करें, यह अप्रासंगिक है। और यह सीएलआर को टोल करने के प्रकार के बाद से प्रयास करने का सही तरीका भी नहीं है। – BoltClock
बस एक उदाहरण आदमी ... – carlosdubusm
@ बोल्टक्लॉक, नहीं, यह नहीं है। अगर अपवाद होता है। यह धीमा है। – CaffGeek