कहां पकड़ने के लिए

Question

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

Answer 1

निश्चित रूप से उपयोगकर्ता के निकटतम प्रयास करने की कोशिश करें - क्योंकि उस स्थान पर आप इसे अपने उपयोगकर्ता के लिए सार्थक रूप में अनुवाद कर सकते हैं।

गहरी प्रयास कैच की आवश्यकता हो सकती है यदि आप उनके साथ कुछ करना चाहते हैं - उदाहरण के लिए, अपवाद को संभालें, या शायद अपवाद को लॉग और पुनर्स्थापित करें।

Answer 2

हम

पालन अपवाद पकड़ नहीं है, तो आप इसके साथ क्या करना है पता नहीं है।

हम कभी भी ऐसे अपवादों को संभाल नहीं सकते जिन्हें हम संभाल या डिफ़ॉल्ट नहीं कर सकते। यह बुलबुला हो जाता है और हम इसे एप्लिकेशन स्तर पर संभालते हैं।

कहें कि क्या आप एक व्यापार ऑब्जेक्ट के लिए एक मान डिफ़ॉल्ट कर सकते हैं, तो आप इसे व्यापार परत में संभाल सकते हैं।

Answer 3

यह इस बात पर निर्भर करता है कि आप वास्तव में इसके बारे में कुछ कहां करना चाहते हैं। आम तौर पर मैं इसे व्यापार परत में पकड़ता हूं, और उसके बाद इसे लॉग करता हूं और संभवतः उपयोगकर्ता को एक संदेश प्रदर्शित करने के लिए कुछ UI फ़ंक्शन को कॉल करता हूं।

मुझे लगता है कि त्रुटियों के साथ व्यापार नियम क्या करना है। यह डेटा परत या यूई परत से अलग होना चाहिए।

Answer 4

सामान्य उत्तर होगा: किसी भी समय आप जो भी फेंक रहे हैं उसे संभालने में पकड़ लें। यही है, निर्णय काफी सरल है। उदाहरण के लिए, ऑब्जेक्ट बनाने के दौरान उठने वाले अपवादों को पकड़ें।

Answer 5

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

try 
{ 
    //do something 
} 
catch(Exception ex) 
{ 
    LogFile.WriteLine(ex.ToString()); 
    throw; 
} 

नोट: नहीं लिखते:

throw ex; 

इस रूप में अपवाद से सभी उपयोगी ढेर जानकारी साफ हो जाएगा।

Answer 6

हमेशा शीर्ष स्तर या contoller स्तर पर कोशिश/पकड़ो।

Answer 7

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

Answer 8

कोशिश करें जहां आप सुनिश्चित हैं कि आप अपवाद को निगल नहीं पाएंगे। यदि आप स्थिरता सुनिश्चित कर सकते हैं तो विभिन्न परतों में एकाधिक प्रयास-पकड़ ब्लॉक ठीक हो सकते हैं।

उदाहरण के लिए, आप अपने डेटा एक्सेस लेयर में एक कोशिश कर सकते हैं ताकि आप कनेक्शन को सही तरीके से साफ कर सकें।लेकिन जैसा कि आप वहां और अधिक नहीं कर सकते हैं, आपको शायद अपवाद को फिर से हटा देना चाहिए।

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

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

बेशक, यह सिर्फ सलाह का एक टुकड़ा है। YMMV। :)

Answer 9

जब मेरे पास एक बहु-परत आर्किटेक्चर है (जो बहुत है) तो मुझे अक्सर एक से अधिक परतों पर एक कोशिश/पकड़ना होगा। उदाहरण के लिए, एक एसक्यूएलएक्सप्शन को पकड़ने वाली दृढ़ता परत में एक कोशिश/पकड़, जो दृढ़ता परत को करने की आवश्यकता होती है (जैसे व्यवस्थापक को सूचित करें) उदाहरण के लिए एक नया अपवाद फेंकता है जो कुछ कोड को समझ में आता है जो दृढ़ता परत को कॉल करता है । एक उदाहरण PersistenceException हो सकता है। अगली परत ऊपर इस बात की परवाह नहीं करती है कि डेटाबेस को दोबारा शुरू करने के लिए अधिसूचित किया जाना चाहिए, लेकिन यह परवाह है कि यह उपयोगकर्ता स्थिति को सहेज नहीं सकता है, इसलिए यह दृढ़ता पकड़ ले सकता है और उपयोगकर्ता को बता सकता है कि उसका नया फोन नंबर ' डेटाबेस में संग्रहीत नहीं है।

Answer 10

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

ज्यादातर परिस्थितियों में, कोशिश करें ... अंत में ब्लॉक आपके कोड में कहीं अधिक आम होना चाहिए ... पकड़ो।

Answer 11

आप केवल अनचाहे कोड को प्रबंधित करने के लिए प्रयास कैच का उपयोग करना चाहते हैं। एक उदाहरण है कि मेरे पास एक COM ऑब्जेक्ट है जिसके साथ मैं संचार कर रहा हूं और मैं नहीं चाहता कि यह खुला रहे और मेमोरी लीक बनाएं। अपवाद जारी रखने की अनुमति देने से पहले अन्य स्वीकार्य विकल्प आपके डेटाबेस में ईवेंट पर त्रुटियों को पकड़ना है।

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

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