त्रुटि हैंडलिंग क्या मुझे अपवाद फेंकना चाहिए? या स्रोत पर संभाल लें?

Question

मेरे पास इस प्रकार का प्रारूप

एएसपीनेट एमवीसी व्यू -> सेवा परत -> रिपोजिटरी है।

तो दृश्य सेवा परत जो उस में व्यापार/मान्यता तर्क है जो बारी-बारी भंडार कॉल कहते हैं।

अब मेरी सेवा परत विधि आम तौर पर एक bool वापसी प्रकार इतना है कि मैं सच लौटा सकते हैं या डेटाबेस क्वेरी अच्छा के माध्यम से चला गया है। या अगर यह असफल रहा। फिर उपयोगकर्ता को एक सामान्य संदेश दिखाया जाता है।

मैं निश्चित रूप से elmah के साथ त्रुटि लॉग इन करूंगा। हालांकि मुझे यकीन नहीं है कि मुझे इस बिंदु पर कैसे जाना चाहिए।

अभी इसी तरह मेरी रिपोजिटरी में अद्यतन, निर्माण, हटाने के लिए शून्य वापसी प्रकार हैं।

तो कहें कि क्या कोई अपडेट विफल रहता है, क्या मुझे अपने भंडार में कोशिश/पकड़ना चाहिए जो त्रुटि को फेंकता है, फिर मेरी सेवा परत इसे पकड़ती है और एल्मा सिग्नलिंग करती है और झूठी वापसी करती है?

या मेरे पास इन रिपोजिटरी विधियों को "बूल" वापस करना चाहिए, रिपॉजिटरी में त्रुटि को आज़माएं/पकड़ें और फिर सेवा परत पर "सत्य" या "झूठी" लौटाएं जो बदले में "सत्य" या "झूठी" देखने के लिए?

अपवाद संचालन अभी भी मुझे confuses त्रुटियों जब जब त्रुटि को पकड़ने के लिए फेंक और कैसे संभाल और।

Answer 1

अंगूठे का नियम मैं हमेशा का उपयोग करें:

इन दो एपीआई पर विचार करें

• निम्न स्तर पर, फेंक जब एक ऑपरेशन असाधारण परिस्थितियों के कारण पूरी नहीं कर सकते हैं।
• मध्यम परतों में, एकाधिक अपवाद प्रकारों को पकड़ें और एक अपवाद प्रकार में पुनः लिखें।
• अंतिम जिम्मेदार पल में अपवादों को संभालें।
• दस्तावेज़!
  1. उपयोगकर्ता क्लिक सबमिट बटन:

यहाँ एक बहु परत ASP.NET MVC अनुप्रयोग (यूआई, नियंत्रक, तर्क, सुरक्षा, भंडार) के लिए स्यूडोकोड में एक उदाहरण है।

नियंत्रक कार्रवाई निष्पादित की जाती है और तर्क (व्यापार) परत में कॉल करती है।

तर्क विधि वर्तमान उपयोगकर्ता पहचान के साथ सुरक्षा में कॉल

• उपयोगकर्ता अमान्य
  • सुरक्षा परत फेंकता SecurityException
  • तर्क परत कैच है, एक अधिक सामान्य त्रुटि संदेश
  • नियंत्रक के साथ LogicException में लपेटता LogicException पकड़ता है, त्रुटि पृष्ठ पर रीडायरेक्ट करता है।
• उपयोगकर्ता वैध है और सुरक्षा देता है

तर्क परत कार्रवाई पूरी करने के

• भंडार में विफल रहता है
  • भंडार फेंकता RepositoryException
  • तर्क परत कैच, रैप भंडार में कॉल LogicException में अधिक सामान्य त्रुटि संदेश
  • नियंत्रक LogicException पकड़ता है, त्रुटि पृष्ठ पर रीडायरेक्ट करता है।
• भंडार सफल होता है

तर्क परत रिटर्न

नियंत्रक सफलता को देखने के लिए पुनर्निर्देश।

नोटिस, तर्क परत केवल एक अपवाद प्रकार - LogicException फेंकता है। किसी भी निचले स्तर के अपवाद जो बबल अप पकड़े जाते हैं, LogicException के एक नए उदाहरण में लपेटा जाता है, जिसे फेंक दिया जाता है। यह हमें कई फायदे देता है।

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

---

वैसे, कुछ भी नहीं कहना है यदि आप ऐसा नहीं कर सकते हैं:

try 
{ 
    var result = DoSomethingOhMyWhatIsTheReturnType(); 
} 
catch(LogicException e) 
{ 
    if(e.InnerException is SqlException) 
    { 
    // handle sql exceptions 
    }else if(e.InnerException is InvalidCastException) 
    { 
    // handle cast exceptions 
    } 
    // blah blah blah 
} 

Answer 2

सबसे पहले वहाँ कोई एक ही रास्ता निश्चित रूप से है और वहाँ एक आदर्श एक तो यह overthink नहीं है नहीं है।

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

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

तो कहते हैं कि एक अद्यतन मेरी भंडार में विफल रहता है अगर मैं आज़माएं/कैच होना चाहिए कि त्रुटि फेंकता है, तब मेरी सेवा परत यह फैल जाती है और elmah संकेत करता है और झूठे रिटर्न?

अद्यतन क्यों विफल हो जाएगा? क्या यह सामान्य प्रक्रिया का हिस्सा होने के लिए एक बिल्कुल सही कारण है? फिर एक अजीब कारण के कारण ऐसा होने पर अपवाद फेंक न दें (मान लीजिए कि रिकॉर्ड को अपडेट होने से पहले अपडेट को अपडेट किया जा रहा है) तो एक अपवाद तार्किक है। इस स्थिति से ठीक होने का कोई रास्ता नहीं है।

Answer 3

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

int int.Parse(string integerValue); // In this case, the method will return int 
            // or it will die! That means your data must be 
            // valid for this method to function. 

bool int.TryParse(string integerValue, out number); // In this case, we expect the data 
                // we passed in might not be fully 
                // valid, hence a boolean. 

Answer 4

एक त्रुटि (या सफलता) कोड अक्सर बेहतर तरीका है, अपवाद लौटने कोड के ऊपर एक विशाल लाभ है लौटते समय या चुपचाप त्रुटियों को दबाने: कम से कम आप उन्हें अनदेखा नहीं कर सकते हैं!

सरल प्रवाह नियंत्रण के लिए अपवादों का दुरुपयोग न करें - यह करने के लिए सबसे शानदार चीज होगी।

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

बस एक त्रुटि कोड लौटाना खतरनाक है क्योंकि कॉलर कोड का निरीक्षण करने से परेशान नहीं हो सकता है और संभवतः अभी भी आगे बढ़ सकता है - भले ही आपके ऐप के तर्क में, वास्तव में कुछ गलत है और इसके साथ निपटने की आवश्यकता है।

तो: अपवाद का दुरुपयोग न करें, लेकिन कोई वास्तविक अपवाद होता है अगर यह है कि यह बारे में कुछ करने की आवश्यकता है फोन करने वाले, मैं निश्चित रूप से असाधारण स्थिति संकेतन के लिए कि प्रणाली का उपयोग कर की सिफारिश करेंगे।

अपवादों को संभालने के लिए: उन लोगों को संभालें जिन्हें आप वास्तव में सौदा कर सकते हैं। जैसे यदि आप फ़ाइल को सहेजने और सुरक्षा अपवाद प्राप्त करने का प्रयास करते हैं, तो उपयोगकर्ता को किसी अन्य स्थान को सहेजने के लिए एक संवाद दिखाएं (क्योंकि उसे उस स्थान को सहेजने की अनुमति नहीं हो सकती है जहां वह चाहता था)।

हालांकि, अपवाद तुम सच के साथ (? क्या आप एक "OutOfMemory अपवाद" के बारे में क्या करना चाहते हैं वास्तव में) सौदा नहीं कर सकते हैं अछूता छोड़ दिया जाना चाहिए - शायद एक फोन करने वाले कॉल स्टैक उन संभाल कर सकते हैं आगे - या नहीं। मार्क