एक्सेप्शन हैंडलिंग, लॉगिंग लिखना कब शुरू करें

Question

आपने अपना एक्सेप्शन हैंडलिंग कोड कब लिखना शुरू किया? जब आप लॉगिंग स्टेटमेंट लिखना शुरू करते हैं।

इस प्रश्न को विस्तृत करने के उद्देश्य से, मान लें कि हम log4net लॉगिंग के साथ .NET प्लेटफ़ॉर्म पर हैं, लेकिन सामान्य तरीके से उत्तर देने के लिए स्वतंत्र महसूस करते हैं।

समाधान: एक विंडोज फॉर्म प्रोजेक्ट। प्रोजेक्ट्स: UI, BusinessRules, DataHandlers

तो, क्या आप अपने डेटाहैंडलर्स के बारे में लिखते हैं जो आपके डेटा मैनिपुलेशन जैसे क्रिएट, रीड, अपडेट, डिलीट को पहले करता है।

फिर अपने व्यावसायिक नियमों के साथ इसका पालन करें

और फिर अपने यूआई या ऊपर के किसी भी अन्य क्रमपरिवर्तन।

कार्यक्षमता के लिए अपने आवेदन का परीक्षण करें।

और फिर अपना एक्सेप्शन हैंडलिंग कोड और अंत में अपना लॉगिंग कोड लिखना शुरू करें ?

अपना एक्सेप्शन हैंडलिंग कोड लिखना शुरू करने का सही समय कब है?

पुनश्च: पुस्तक क्लीन कोड में , वे कहते हैं कि अपनी कोशिश को पकड़ें-अंत में पहले ब्लॉक करें। यह सवाल पूछने के लिए मुझे प्रेरित किया।

Answer 1

जब आप उस चीज़ को लिख रहे हों, जो अपवाद के कारण हो सकती है, तो आप अपना अपवाद हैंडलिंग कोड लिखें।

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

दूसरी ओर, यदि आप एक ऐसा पार्सर लिख रहे हैं जो अपवादों को उठाता है जब यह एक विकृत प्रोटोकॉल डेटा यूनिट से सामना करता है, तो आप उन अपवादों के लिए अपवाद-हैंडलिंग कोड नहीं लिख सकते हैं जो पार्सर पैदा करता है । (लेकिन निश्चित रूप से आप परीक्षण लिख रहे हैं कि कैसे और कब और क्यों पार्सर अपवाद उठाता है!)

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

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

Comments

कोशिश-कैच-

— एंड

C ++ में, अंत में , और बहुत अच्छे कारणों के लिए नहीं है। RAII बहुत बेहतर है।

— डेविड थॉर्नले

Answer 2

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

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

Answer 3

निर्भर करता है कि आप क्या कर रहे हैं

अपवादों के लिए:

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

यदि आप कुछ ऐसा लिख ​​रहे हैं, जिसमें प्रदर्शन की आवश्यकता है और त्रुटियों की कम संभावना है, तो त्रुटि संचालकों को रखने के लिए एक सार्थक जगह की कमी है जो त्रुटि संचालकों को लिखते हैं जहां परीक्षण साबित करता है कि आपको उनकी आवश्यकता है।

या तो मामले में, यदि आपके पास त्रुटि के साथ कुछ भी उपयोगी नहीं है, तो इसे बुलबुला मानने पर विचार करें (कोई हैंडलर नहीं)

लॉगिंग के लिए:

यदि आपको ऑडिट ट्रेल की आवश्यकता है तो आपको पहले लॉगिंग लिखना चाहिए। यदि आप त्रुटियों को सभी तरह से शीर्ष पर रखते हैं, तो आपको कुछ लॉगिंग प्रदान करने की आवश्यकता है, साथ ही लॉग को कैप्चर किया जा सकता है।

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

Comments

विस्तृत उत्तर के लिए धन्यवाद। लॉगिंग के संबंध में, यदि आपको ऑडिट ट्रेल की आवश्यकता है तो आप पहले लॉगिंग से क्यों शुरू करेंगे। जब मैं इसकी कार्यक्षमता के साथ काम कर रहा हूं तो मैं उन्हें क्यों नहीं लिख सकता हूं? कोई खास कारण?

— कानिनी

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

— बिल

Answer 4

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

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

Answer 5

जब आपको इसकी आवश्यकता हो, तब इसे लिखें, लेकिन प्रारंभ से उनके समावेश के लिए डिज़ाइन करें।

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