मेरे पास एक स्कैला सहायक विधि है जो वर्तमान में एक यूआरएल लाने की कोशिश करती है और उस वेबपृष्ठ के एचटीएमएल के साथ एक विकल्प [स्ट्रिंग] वापस कर देती है।वापस लाने के लिए बेहतर कोई नहीं या यूआरएल लाने पर अपवाद फेंकना?
किसी भी अपवाद नहीं हैं, तो (विकृत यूआरएल,, समय समाप्ति पढ़ आदि ...) या यह एक कोई नहीं देता है अगर कोई समस्या है। सवाल यह है कि क्या अपवाद फेंकना बेहतर होगा ताकि कॉलिंग कोड अपवाद लॉग कर सके या क्या इस मामले में कोई भी वापस लौटना बेहतर नहीं है?
अपवाद बनाना महंगा है क्योंकि स्टैक ट्रेस भरना है। सामान्य वापसी की तुलना में अपवादों को फेंकना और पकड़ना भी अधिक महंगा है। यह देखते हुए कि, आप स्वयं से ये प्रश्न पूछ सकते हैं:
आप कॉल करने वाले को एक त्रुटि से निपटने के लिए मजबूर करना चाहते हैं? यदि ऐसा है, तो अपवाद फेंक न दें, क्योंकि स्कैला में कोई चेक-अपवाद तंत्र नहीं है जो कॉलर को पकड़ने के लिए मजबूर करता है।
किसी त्रुटि के मामले में, क्या आप इस बारे में विवरण शामिल करना चाहते हैं कि यह क्यों विफल हुआ? यदि नहीं, तो आप सिर्फ Option[A] लौट सकते हैं, जहां A अपनी वापसी प्रकार है, और फिर आप या तो Some(validContent) या None, बिना किसी अतिरिक्त स्पष्टीकरण के साथ होगा। यदि हां, तो आप Either[E, A] या स्कालाज़ Validation[E, A] जैसे कुछ वापस कर सकते हैं। इस विकल्प में कॉलर को E त्रुटि को संसाधित करने के लिए स्वतंत्र होने पर परिणाम को किसी भी तरह से अनचाहे करने के लिए मजबूर किया जाता है। अब E क्या होना चाहिए?
आप विफलता के मामले में एक स्टैक ट्रेस प्रदान करने के लिए करना चाहते हैं? यदि हां, तो आप Either[Exception, A] या Validation[Exception, A] लौट सकते हैं। यदि आप वास्तव में अपवाद के साथ जाते हैं, तो आप Try[A] का उपयोग करना चाहेंगे, जिनके दो संभावित मामले Failure(exc: Throwable) और Success(value: A) हैं। ध्यान दें कि आप निश्चित रूप से फेंकने की लागत का खर्च उठाएंगे। यदि नहीं, तो आप शायद Either[String, A] लौट सकते हैं (और यह याद रखने के लिए अतिरिक्त सावधान रहें कि Right का अर्थ है सफलता या विफलता - Left आमतौर पर त्रुटियों के लिए उपयोग की जाती है, और "दाएं" मान के लिए Right - Validation शायद स्पष्ट है)। आप चाहते हैं वैकल्पिक रूप से एक स्टैक ट्रेस लौटने के लिए, आप लिफ्ट के Box[A] इस्तेमाल कर सकते हैं, जो Full(validContents), Empty कोई अतिरिक्त स्पष्टीकरण (बहुत ने यहां तक Option[A] के समान) के साथ हो सकता है, या संकेत मिलता है एक Failure जो एक त्रुटि स्ट्रिंग स्टोर कर सकते हैं और/या एक फेंकने योग्य (और अधिक)।
आप शायद क्यों यह असफल करने के लिए के रूप में कई संकेत प्रदान करने के लिए करना चाहते हैं? फिर Either[Seq[String], A] वापस करें। यदि आप इसे अक्सर करते हैं, तो संभवतः आप स्कालाज़ और Validation[NonEmptyList[String], A] का उपयोग करना चाहेंगे, जो कुछ अन्य अच्छी उपहार प्रदान करता है। इसके बारे में अधिक जानकारी के लिए इसे देखें या these usage examples देखें।
ग्रेट सारांश! निजी तौर पर, मैं किसी भी समय [स्ट्रिंग, ...] का उपयोग करता हूं, ज्यादातर समय स्कालज़ का सत्यापन स्पष्ट दिखता है। –
मुझे लगता है कि इस मामले में, अपवादों को लॉग इन करना महत्वपूर्ण है, तो हर तरह से अपवाद फेंक दें (और संभवतः विकल्प के बजाय स्ट्रिंग वापस करें)। अन्यथा आप भी किसी को वापस नहीं कर सकते हैं। एक चेतावनी- अन्य कारणों के लिए अपवाद हो सकते हैं जिन्हें आप पूर्ववत नहीं करते हैं, इस मामले में कैच-सब कुछ कोड बनाना खतरनाक हो सकता है।
एक बात है कि तुम कर सकते हो लिफ्ट के Box प्रणाली की तरह कुछ है।एक बॉक्स अनिवार्य रूप से एक विकल्प है, लेकिन इसमें कुछ विशेषताएं शामिल हैं: FullSome की तरह है, EmptyNone की तरह है, लेकिन लिफ्ट एक कदम आगे बढ़ता है और Failure है, जो Empty जैसा है लेकिन एक कारण/संदेश।
अंगूठे का सामान्य नियम "यदि आप अपवाद को संभाल सकते हैं, इसे संभाल लें"। तो अनुमान लगाने के लिए पर्याप्त संदर्भ नहीं है। आप tryFetchUrl/fetchUrl विधियों की जोड़ी का उपयोग कर सकते हैं।
यदि यह एक सहायक विधि है, तो मुझे लगता है कि यह निजी है। यदि यह निजी है, तो आप कॉलर हैं। यदि आप कॉलर हैं, तो आप वह हैं जिनके बारे में सारी जानकारी है कि क्या होना चाहिए, इसलिए जो भी आप चाहते हैं। अन्यथा जीन का जवाब देखें। – agilesteel