रूबी के लिए लोडररर को बचाने के विकल्प हैं?

Question

मैंने ब्लॉग पोस्ट JRuby Performance: Exceptions are not flow control पढ़ा जो असाधारण परिस्थितियों को छोड़कर अपवादों का उपयोग करने से बचने की वकालत करता था।

मुझे एहसास हुआ कि मैं नियमित आधार पर लोडर्रॉर्स को संभालने के लिए बचाव का उपयोग करने का दोषी हूं।

क्या require का कोई विकल्प है जो फ़ाइल मौजूद होने पर फ़ाइल लोड करने का प्रयास करता है, लेकिन अगर ऐसा नहीं होता है तो अपवाद नहीं फेंकता है?

पृष्ठभूमि: आप सोच रहे हैं कि "तुम क्यों मिल गया है की आवश्यकता है कि आप पूरी तरह की आवश्यकता नहीं है?", यहाँ मेरी कहानी है:

1. जब मैं रूबी 1.8 के लिए प्रोग्रामिंग था, मैं require "rdoc/usage" इस्तेमाल किया ताकि अगर मैं अपने कमांड लाइन एप्लिकेशन में पैरामीटर की सही संख्या में प्रवेश नहीं करता तो मैं उपयोग जानकारी दे सकता हूं। यह आउट ऑफ़ द बॉक्स 1.9 पर एक अपवाद फेंकता है।
2. मेरे एप्लिकेशन के हिस्से में Win32ole में हेरफेर करने के लिए कोड शामिल है जब यह मेरे विंडोज डेस्कटॉप पर चल रहा है। इससे लोडरर का कारण बनता है यदि शामिल फाइलें लिनक्स सर्वर के तहत चलती हैं जो भारी कम्प्यूटेशनल काम करता है। Win32ole का उपयोग करने वाली फ़ाइलों में अन्य कोड भी है जो मेरे टेस्ट सूट में परीक्षण किया जाता है, इसलिए लिनक्स के तहत मेरा टेस्ट सूट चलाते समय, मुझे उन फ़ाइलों की आवश्यकता होती है। मुझे ऐसी फाइलों को विभाजित करना चाहिए, लेकिन यह यक शेविंग की तरह थोड़ा लगता है।

Answer 1

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

आपके दूसरे मामले में, ओएलई जैसे मंच विशिष्ट चीजों को करने की कोशिश करने से पहले RUBY_PLATFORM या sys-uname जांचने के लिए अधिक समझ हो सकती है। कभी-कभी यक को शेविंग की आवश्यकता होती है। इसमें, यदि आप विंडोज़ पर हैं तो आप वास्तव में आवश्यकताएं विफल करना चाहते हैं, जबकि यदि आप लिनक्स पर हैं, तो आप बिल्कुल आवश्यकता नहीं चाहते हैं; आप अपवाद के बजाय अपवाद के साइड इफेक्ट्स का उपयोग कर रहे हैं।

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

Answer 2

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

वैसे, यदि आपके पास कोई तरीका है जो वास्तव में प्रदर्शन-संवेदनशील (यानी कई बार निष्पादित) है, लेकिन आप एक "गोटो" चाहते हैं जो आपको कई ब्लॉकों से बाहर निकलने और यहां तक ​​कि कॉल स्टैक तक पहुंचने की अनुमति देता है (एक अपवाद की तरह), throw और catch का उपयोग करें। वे raise और rescue के समान हैं, लेकिन बहुत तेज़ हैं। अपवाद बढ़ाने की अधिकांश प्रदर्शन लागत स्टैक ट्रेस भरने से आती है, और throw ऐसा नहीं करता है।

आईएमएचओ, begin; require "..."; rescue LoadError बेवकूफ रूबी है और किसी भी तरह से खराब अभ्यास नहीं माना जाता है, भले ही लोग "प्रवाह नियंत्रण के अपवादों का उपयोग करते हुए" के बारे में क्या कहते हैं। यदि आपकी स्क्रिप्ट को सामान्य रूप से विंडोज़ पर निष्पादित किया जाता है, तो लिनक्स पर चलने पर सही ढंग से "असाधारण स्थिति" माना जा सकता है, और अपवादों का उपयोग करने योग्य है। आम तौर पर, यदि आप जिस फ़ाइल को लोड करना चाहते हैं वह वहां नहीं है, तो यह एक "असाधारण स्थिति" है - यही कारण है कि require पहली जगह अपवाद उठाता है!

अपने सिर को ऊपर उठाओ, आदमी! शत्रुओं को सरल, सामान्य-ज्ञान कोड का उपयोग करने के लिए आपको दोषी महसूस न करने दें!