क्या सुरक्षा प्रतिबंधों के कारण कोई सेवा शून्य हो सकती है या अपवाद छोड़ देना चाहिए? [बन्द है]


11

मैं इस मुद्दे पर एक अधिक अनुभवी डेवलपर के साथ थोड़ी असहमति में हूं, और सोच रहा हूं कि दूसरे इसके बारे में क्या सोचते हैं; हमारा वातावरण जावा, EJB 3, सेवाओं, आदि है।

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

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

सेवा को लिखने वाले अधिक अनुभवी डेवलपर ने तर्क दिया कि डेटा के लिए पूछना एक त्रुटि स्थिति नहीं है, और यह कि अपवाद केवल एक त्रुटि स्थिति में फेंक दिया जाना चाहिए, न कि जब उपयोगकर्ता के पास डेटा तक पहुंच नहीं है। यह डेटा अक्सर एक जीयूआई में देखा जाता है, और उन उपयोगकर्ताओं के लिए जो सही अनुमतियों के बिना हैं, ये चीजें केवल "मौजूद नहीं हैं"। तो, संक्षेप में: पूछना गलत नहीं है, इसलिए कोई अपवाद नहीं है। उन उपयोगकर्ताओं के कारण विधियाँ वापस आती हैं, क्योंकि वे चीजें "अस्तित्व में नहीं हैं"। जब उपयोगकर्ता उस चीज़ को बनाने की अनुमति नहीं थी, तो विधियाँ वापस लाएँ।

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



@ChrisF: 1) लोगों के बारे में है कि वे अशक्त संदर्भों को नहीं दिखाते हैं। कई मामलों में वे उपयुक्त हैं, मुझे नहीं लगता कि वे इस एक में हैं। 2) मापदंडों की जाँच करने के बारे में है, और एक अपवाद को फेंकने के रूप में परिणाम के एक मुखर तरह नहीं होगा? 3) अपवाद बनाम त्रुटि कोड भी एक अलग मुद्दा है क्योंकि वे दोनों "दिखाने" के तरीके हैं जो गलत हो गया। त्रुटि कोड उपयुक्त हैं यदि उदाहरण के लिए आपको एक सिस्टम को सूचित करने की आवश्यकता है जो अपवादों का समर्थन नहीं करता है या यदि आप नहीं चाहते कि एंड-यूज़र किसी कोड के अलावा कुछ और देखें।
Svish

मैं यहाँ जिस मुद्दे के बारे में पूछ रहा हूँ, वह यह है कि "कुछ दिखावा मौजूद नहीं है या नहीं हुआ है" बनाम "यह बताने के कारण कि कुछ मौजूद नहीं है या नहीं हुआ है"।
शविश

3
मैंने सुझाव नहीं दिया कि वे डुप्लिकेट थे - सिर्फ इसलिए कि उनके पास आपके लिए उपयोगी जानकारी हो सकती है।
ChrisF

सच है, इस बारे में खेद है! इसे किसी कारण के लिए "संभव डुप्लिकेट" टिप्पणी के रूप में लिया ... शायद नींद की कमी के कारण, हेह।
Svish

जवाबों:


19

अपवाद केवल तभी फेंका जाना चाहिए जब कोई त्रुटि हो और किसी चीज़ के लिए पूछना एक त्रुटि नहीं है।

किसी चीज़ के लिए पूछना एक त्रुटि हो सकती है, लेकिन आपके द्वारा मांगी गई किसी चीज़ की अनुमति नहीं होना निश्चित रूप से कुछ त्रुटि है। अपवाद विशेष परिस्थितियों को रिपोर्ट करने का एक वैकल्पिक तरीका है, जिसका उपयोग विशेष रिटर्न मानों के बजाय किया जाता है (जैसे कि null, जैसा कि आपने लिखा है, अगर पूरी तरह से कोई मदद नहीं मिली है तो> 1 संभावित कारण हैं कि चीजें क्यों भटक सकती हैं (भले ही वहां हो) अब ठीक 1 संभावित कारण, अगले संस्करण में 2 संभावित कारण हो सकते हैं, इसलिए nullरिटर्न वैल्यू के रूप में उपयोग करना विफलता को दर्शाता है जो कि खुद को कोने में चित्रित कर रहा होगा))। यदि सेवा किसी भी तरह से रिपोर्ट नहीं करती है तो वह क्यों नहीं करेगी जो आपने पूछा है, तो यह निश्चित रूप से खराब डिजाइन है।

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

String.substring()IndexOutOfBoundsExceptionयदि सूचकांक सीमा से बाहर है, तो फेंकता है। मैं nullइसके बजाय लौटने के किसी भी फायदे के बारे में नहीं सोच सकता, भले ही - दार्शनिक रूप से - कोई यह तर्क दे सकता है कि Stringइसकी सीमा के बाहर कुछ भी नहीं है, इसलिए nullएक तार्किक वापसी मूल्य होगा। तार्किक-दार्शनिक होने और व्यावहारिक होने के नाते स्पष्ट रूप से दो अलग-अलग जानवर हैं।


यदि विकल्प () आउट-ऑफ-बाउंड इंडेक्स के लिए एक मान लौटाने जा रहा है, तो इसे इंडेक्स के बीच स्ट्रिंग के हिस्से को वापस करना चाहिए, संभवतः खाली। कि कुछ कॉलिंग कोड में एक परीक्षण बचा सकता है।
केविन क्लाइन

2
हां, यह कभी न खत्म होने वाला "खाली मूल्य" बनाम अशक्त-दोष है: क्या आउट-ऑफ-बाउंड इंडेक्स के लिए विकल्प शून्य या रिक्त स्ट्रिंग होना चाहिए? मुझे नहीं पता, दोनों प्रभावी रूप से "कुछ भी नहीं" (ठीक है, शायद अशक्त "एक खाली स्ट्रिंग की तुलना में" अधिक कुछ नहीं है?), लेकिन न तो उस जानकारी की मात्रा देता है जो एक अपवाद करता है।
जूनस पुलकका

@kevincline: जब तक कोई एक फ्रेमवर्क का उपयोग नहीं कर रहा है जहां एक शून्य संदर्भ एक रिक्त स्ट्रिंग को इंगित करने का एक मुहावरेदार साधन है, मुझे substringअशक्त संदर्भ वापस करने के लिए कोई आधार नहीं दिखता है । IMHO, दो अलग-अलग कार्य होने चाहिए - जिनमें से एक या तो वर्णों की अनुरोधित संख्या को वापस करने या एक अपवाद को फेंकने का वादा करता है, और इनमें से एक जितना संभव हो उतना वापस लौटता है। प्रत्येक विधि कुछ संदर्भों में दूसरे से काफी बेहतर होगी।
सुपरकाट

@ सुपरफ़ैट: ​​मैं अशक्त लौटने के बारे में कुछ नहीं कहा। मैंने कहा 'वापसी ... हिस्सा ... संभवतः खाली'। ओरेकल को छोड़कर एक खाली स्ट्रिंग शून्य नहीं है।
केविन क्लाइन

@JoonasPulakka: मुझे आपको मेरी पिछली टिप्पणी पर ध्यान देना चाहिए।
सुपरकैट

5

यह नीचे आता है कि अनुबंध क्या है। यदि आपका अनुबंध कहता है कि आप किसी ऐसी चीज़ का अनुरोध कर सकते हैं जो मौजूद नहीं है, तो यह कहना चाहिए कि क्या होता है (अशक्त, या अशक्त वस्तु)।

दूसरी ओर, यदि आपका अनुबंध कहता है कि आपको पहले एक अलग विधि ( DoesSomethingExist()) को कॉल करना चाहिए और फिर विधि को कॉल करना चाहिए Get, तो आपका अनुबंध कह सकता है कि आप केवल उन चीज़ों को प्राप्त कर सकते हैं जो मौजूद हैं, और अपवाद को फेंक दें यदि वे नहीं करते हैं। अपवाद संदेश कुछ ऐसा कह सकता है, " DoesSomethingExist()पहले कॉल करना सुनिश्चित करें " जो एक उपयोगी त्रुटि संदेश है।


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

4

सवाल का एक भी आकार-फिट-सभी जवाब नहीं है। अपवाद का उपयोग करना है या अशक्त करना स्थिति पर निर्भर करता है।

इस विशुद्ध रूप से एक हठधर्मी दृष्टिकोण से देखने के बजाय, इंटरफ़ेस को उपयोगकर्ता इंटरफ़ेस के रूप में देखें । उपयोगकर्ता इंटरफ़ेस उपयोग करने योग्य होना चाहिए । तो कुछ करने के "सही" तरीके पर आपकी खुद की राय की परवाह किए बिना, अपने इंटरफ़ेस का उपयोग करने वाले किसी के दृष्टिकोण से सबसे अधिक प्रयोग करने योग्य विधि चुनें।

यदि कॉलर को यह जानना होगा कि किसी वस्तु को वापस क्यों नहीं किया जा रहा है, तो एक अपवाद उपयुक्त है। यदि, हालांकि, सामान्य अवधारणा "यदि आपके पास अनुमति नहीं है, तो यह मौजूद नहीं है", शून्य स्वीकार्य है।

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

यदि, दूसरी ओर, आपके पास कोई प्रारंभिक कनेक्शन या लॉगिन कदम नहीं है, तो एक अपवाद समझ में आता है। यदि कॉलर को पता है कि एक आइटम मौजूद है और वे इसे वापस नहीं पा रहे हैं, तो एपीआई केवल एक अशक्त वापस करने के लिए सहायक नहीं है।

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

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

तो, इस पर एक धार्मिक युद्ध में मत जाओ, तय करें कि इस विशेष समस्या के लिए क्या सही है।


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

1
और एक डेवलपर के रूप में मुझे इस बात की परवाह है कि कुछ गलत क्यों है, भले ही अंत-उपयोगकर्ता को इसके बारे में पता होना चाहिए।
Svish

पूरी तरह से ब्रायन से सहमत हैं। यहां तक ​​कि develpers उपयोगकर्ता हैं, अर्थात कुछ अन्य डेवलपर्स कोड का उपभोग करते हैं। थ्रो या नल का अवरोह एक प्रकार का इंटरफ़ेस / गुइ है जो विशिष्ट कार्य के लिए सहायक होना चाहिए। सिर्फ तर्क या दर्शन के सामान्य शब्द से नहीं।
स्वतंत्र

3

मुझे निश्चित रूप से लगता है कि यह एक खराब डिजाइन है । नल-सूचक मेरे लिए एक वैध उत्तर नहीं है और इसे प्रबंधित करने के लिए मुश्किल हो सकता है।

यदि उपयोगकर्ता उचित क्रेडेंशियल के बिना किसी सेवा को जोड़ने का प्रयास करता है, तो मुझे एक स्पष्ट और संक्षिप्त उत्तर के साथ जवाब देना चाहिए। उत्तर एक अपवाद या एक विशेष वस्तु हो सकता है, लेकिन अशक्त नहीं।

नेटवर्क लिंक टूट जाने या अन्य अप्रत्याशित महत्वपूर्ण खराबी होने पर आपको अशक्त उत्तर छोड़ देना चाहिए।

इसके अलावा, जिस समय आप यह समझने में खर्च करते हैं कि आपको अशक्त क्यों है एक मजबूत तर्क है। किसी भी कोड को समझना और उपयोग करना आसान होना चाहिए। एक शून्य मान होने की बात नहीं है।


अपने अंतिम वाक्य से, क्या आपका मतलब है "आपको नेटवर्क लिंक टूटने आदि पर ही अशक्त होना चाहिए ।" या "आपको नेटवर्क लिंक टूटने आदि पर अशक्त लौटने से रोकना चाहिए " ?
Péter Török

@ Péter Török: मैं "वापसी अशक्त" के स्पष्ट उपयोग की अनुशंसा नहीं करता हूं। हालांकि जब एक बड़ी टूट होती है, तो यह कुछ सेवा के लिए अशक्त होने के लिए स्वीकार्य है।
अमीन

यदि एक अप्रत्याशित महत्वपूर्ण खराबी हुई तो क्या कोई अपवाद अधिक उपयुक्त नहीं होगा?
Svish

2
@Amine: मैं कहूंगा कि यह सबसे कम उपयुक्त मामला है जिसके लिए अशक्त वापस आना है।
माइकल बोर्गवर्ड 14

@ सविश: यदि आप प्रमुख टूटने का पता लगा सकते हैं, तो निश्चित रूप से एक अपवाद महान होगा।
अमीन

3

अच्छे सॉफ्टवेयर डिजाइन को ध्यान में रखते हुए, आपको अपने प्रोजेक्ट के जीवन के बारे में सोचना चाहिए।
लौटकर null, जैसा कि कहा गया है, आप ग्राहक को कोई जानकारी नहीं देते हैं। देखो कि तुम पर क्या ख़ुशी है, पहले तुम्हें एहसास नहीं था कि समस्या कहाँ थी। इसके अलावा, अगर कोई प्रलेखन नहीं दिया जाता है, तो यह एक गड़बड़ है।

एक अपवाद को फेंककर, आप बता सकते हैं कि क्या गलत हुआ। यदि आप चाहते हैं तो आप प्रदर्शित पाठ को और भी विशिष्ट बना सकते हैं।

दूसरी ओर, nullआप लौटकर ग्राहक को यह जाँचते हैं कि यह क्या चल रहा है।

इसके अलावा, आपको एहसास हुआ कि एक समस्या थी क्योंकि आप कहीं और मिल गए थे NullPointerException। अब कल्पना करें कि आप उस फ़ंक्शन की वापसी को स्टोर नहीं करते हैं ... आपको उस फ़ंक्शन को प्रत्येक कॉल को if elseब्लॉक के साथ घेरने के लिए मजबूर किया जाएगा ...

मेरे दृष्टिकोण से, वापसी nullएक बुरा अभ्यास है।


2

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

मेरे दृष्टिकोण से, इसका कोई मतलब नहीं है।

अनुमति के बिना डेटा के लिए क्वेरी करना एक अपवाद के रूप में परिणाम होना चाहिए , क्योंकि यह एक अप्रत्याशित परिणाम है - बिना किसी परिणाम के - उचित पहुंच के बिना।

सादृश्य : एक GETप्राधिकरण के बिना उत्तरदायित्व 200 okकोई डेटा नहीं है, यह वास्तव में नहीं है 401 Unauthorized


1

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

एक सार्थक प्रतिक्रिया आवेदन को तार्किक विकल्प बनाने की अनुमति दे सकती है कि आगे क्या करना है या समस्याओं को कैसे हल करना है।


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

"सिस्टम के डिजाइन की आवश्यकता है कि आप नहीं जानते" से आपका क्या मतलब है? किस तरह का डिजाइन हो सकता है?
Svish

2
यदि सुरक्षा नीति कहती है कि आपको इसे देखने की अनुमति नहीं है, तो ज्यादातर मामलों में आपको यह जानने में सक्षम नहीं होना चाहिए कि यह मौजूद है या तो। यह "वापस नहीं मिला" पूरी तरह से स्वीकार्य बनाता है।
Blrfl

1

यदि मूल कारण एक अनधिकृत उपयोगकर्ता है, तो मैं एक हार्ड-संदेश-पृष्ठ (और किसी को परवाह करने वाली अधिसूचना) के पुनर्निर्देशन के साथ शायद एक कठिन HTTP 401 प्रतिक्रिया पसंद करता हूं। प्राधिकरण-संबंधित कारण अधिक केस-बाय-केस हैं; HTTP त्रुटियों (403, कहना) को वापस करने के लिए तर्क हैं और सेवा प्रतिक्रिया में विशेष रूप से अच्छी तरह से गठित कोड / संदेशों को वापस करने के लिए तर्क हैं।

अपवादों को केवल असाधारण cirumstances में इस्तेमाल किया जाना चाहिए और इसका मतलब है कि कुछ गलत हो गया है। मैं असहमत हूं कि उन्हें "अनुमति नहीं दी गई" का मतलब करने के लिए अतिभारित होना चाहिए। (शून्य रिटर्न मान के लिए भी यही सच है: मैं असहमत हूं कि इसका उपयोग "अनुमति नहीं" के लिए किया जाना चाहिए)।


ठीक है, जीयूआई में आप ऐसा कर सकते हैं, लेकिन बीन के लिए उस सेवा को लागू करना जो पर्दे के पीछे की चीजें हैं जो आपके पास केवल अपवाद हैं और आपके निपटान में विशेष रिटर्न मान हैं। मैं निश्चित रूप से इसका मतलब यह नहीं है कि उपयोगकर्ता को अपवाद मिलना चाहिए, लेकिन उदाहरण के लिए अपवाद वेब सेवा / सर्वलेट / जो कुछ भी पकड़ा जा सकता है और फिर जो उपयुक्त है उसे पकड़ा जा सकता है। कहीं न कहीं, कठोर http 4xx पृष्ठ, या कुछ और के लिए पुनर्निर्देशित करें।
Svish

अच्छी बात है, लेकिन आप इन मामलों को पकड़ने के लिए AOP जैसे प्रतिमान को नियोजित कर सकते हैं। पहलू किसी दिए गए ऑपरेशन को कॉल करने के विशेषाधिकार के लिए परीक्षण कर सकता है और प्रसंस्करण को पुनर्निर्देशित कर सकता है / प्रसंस्करण को उचित रूप में जारी रखने की अनुमति दे सकता है।
मार्क

0

शैतानों के वकील की भूमिका निभाने के लिए मैं वापसी करने की दिशा में प्रयास करूंगा।

मेरी राय में इस तरह की प्रतिक्रिया लगभग स्वीकार्य है और इस मामले में, जैसा कि इस मामले में है, जब सुरक्षा शामिल है।

गलती से अपने सिस्टम का विवरण देना बहुत आसान है, जिसके बारे में अनधिकृत लोगों को पता नहीं होना चाहिए। इससे बचना चाहिए।

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

इस प्रकार, इस विशेष मामले में मैं कहूंगा कि वापसी करना लगभग ठीक है nullलेकिन मैं मानता हूं कि इसके साथ काम करना बहुत अप्रिय होगा।


हाँ, मैं असहमत हूँ। मेरी राय में उचित प्रतिक्रिया एक अपवाद होगी, लेकिन उपयोगकर्ता नाम नहीं मिला और गलत पासवर्ड दोनों के लिए एक ही। FailToLogin, InvalidCredentials, जो भी हो।
Svish

@ सविश - लेकिन अगर आप असफलता के कारण के रूप में बिल्कुल भी कोई संकेत देने की कोशिश कर रहे हैं तो वापस लौटना nullबिल्कुल मददगार प्रतिक्रिया है। सिस्टम के बारे में कुछ पता करने के लिए लगभग कुछ और संभावित रूप से इस्तेमाल किया जा सकता है। ओपी ने शिकायत की थी क्योंकि न केवल nullवापसी ने समझाया था कि यह कुछ भी नहीं है यह अनपेक्षित भी था। यह जानबूझकर किया गया उद्देश्य है ... बिल्कुल कुछ नहीं कहना और अनहेल्दी होना। मेरे विचार में मिशन पूरा हुआ।
OldCurmudgeon 10

खैर, ऐसा हो सकता है, लेकिन मैं फिर भी कहूंगा कि ऐसा करना बुरा है। कम से कम एक सिस्टम के अंदर। किनारों पर जहां एंड-यूज़र चीजों को देखते हैं, तो यकीन है, मैं सहमत हो सकता हूं। लेकिन सिस्टम के अंदर, हम डेवलपर उपयोगकर्ता हैं, और दुनिया में हम अपने लिए चीजों को और अधिक भ्रमित क्यों करना चाहेंगे? मानो सॉफ्टवेयर विकसित करना पहले से ही कठिन नहीं है ...
Svish

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

-2

मुझे लगता है कि वापसी अशक्त नहीं है, जब ग्राहक इस विधि को लागू करता है और अशक्त लौटता है, तो ग्राहक को पता नहीं होता है कि क्या हुआ और क्यों यह अशक्त लौट आया। इसलिए हमें क्रियान्वयन को फेंक दिया जाना चाहिए जो समझ में आता है और इस निष्पादन का वर्णन करने के लिए एक दस्तावेज प्रदान करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.