सी # में एक एंटरप्राइज़ प्रोजेक्ट के लिए त्रुटि कोड पैटर्न बनाने के लिए सर्वश्रेष्ठ अभ्यास [बंद]

Question

मैं एक उद्यम परियोजना पर काम कर रहा हूं जिसे कई एसएमबी और एंटरप्राइजेज में तैनात किया जाएगा।
इस परियोजना के लिए समर्थन संघर्षपूर्ण होगा और इसलिए मैं त्रुटियों के लिए एक कोडिंग पैटर्न बनाना चाहता हूं ( जैसे HTTP स्थिति कोड )। यह मदद डेस्क लोगों को दस्तावेज़ों को संदर्भित करने और जितनी जल्दी हो सके समस्याओं का निवारण करने में सक्षम करेगा।

ऐसा करने के लिए सर्वोत्तम अभ्यास और सिफारिशें क्या हैं?
ऐसा करने के लिए कोई भी मदद उपयोगी होगी।

Comments

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

— बेन मैकडॉगल

निर्भर करता है कि आपका व्यवसाय कैसे संरचित है। C # में हमने हमेशा उपयोगकर्ता को हमें StackTrace को मेल करने या त्रुटि संदेश के विवरण से कॉपी / पेस्ट करने की संभावना दी (हमारे पास कोई सुरक्षा की कोई सख्त आवश्यकता नहीं थी)।

— फाल्कन

Answer 1

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

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

यह है कि मैं इसे कैसे व्यवस्थित करूंगा (ध्यान दें कि अंक 2-6 भाषा अज्ञेय हैं):

1. एक अतिरिक्त ErrorCodeसंपत्ति के साथ एक कस्टम अपवाद प्रकार का उपयोग करें । मुख्य लूप में पकड़ इस क्षेत्र को सामान्य रूप से रिपोर्ट करेगा (लॉग फ़ाइल / त्रुटि पॉप-अप / त्रुटि उत्तर)। अपने सभी कोड में एक ही अपवाद प्रकार का उपयोग करें।
2. 1 से शुरू न करें और अग्रणी शून्य का उपयोग न करें। सभी त्रुटि कोडों को समान लंबाई में रखें, इसलिए एक गलत त्रुटि कोड को स्पॉट करना आसान है। 1000 से शुरू करना आमतौर पर काफी अच्छा होता है। हो सकता है कि उन्हें उपयोगकर्ताओं के लिए स्पष्ट रूप से पहचान योग्य बनाने के लिए एक अग्रणी 'ई' जोड़ें (विशेष रूप से उपयोगी है जब समर्थन डेस्क को उपयोगकर्ताओं को निर्देश देना है कि वे त्रुटि कैसे प्राप्त करें)।
3. सभी त्रुटि कोड की सूची रखें, लेकिन अपने कोड में ऐसा न करें । डेवलपर्स के लिए विकी-पेज पर एक छोटी सूची रखें, जिसे एक नए कोड की आवश्यकता होने पर वे आसानी से संपादित कर सकें। हेल्प डेस्क की अपनी विकि पर एक अलग सूची होनी चाहिए।
4. त्रुटि कोड पर एक संरचना को लागू करने का प्रयास न करें। हमेशा हार्ड-टू-क्लासिफिकेशन त्रुटियां होंगी और आप घंटों तक चर्चा नहीं करना चाहते हैं कि क्या त्रुटि 45xx समूह में या 54xx समूह में होनी चाहिए। व्यावहारिक हो ।
5. अपने कोड में प्रत्येक फेंक को एक अलग कोड असाइन करें। हालांकि आपको लगता है कि यह एक ही कारण है, हेल्प डेस्क को अलग-अलग मामलों में अलग-अलग काम करने की आवश्यकता हो सकती है। यह उनके लिए आसान है कि उनकी Eiki में "E1234: E1235 देखें", उपयोगकर्ता को यह स्वीकार करने के लिए कि उसने क्या गलत किया है।
6. यदि सहायता डेस्क इसके लिए पूछता है तो स्प्लिट त्रुटि कोड। if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");आपके कोड की एक सरल रेखा हेल्प डेस्क के लिए आधा घंटा बचा सकती है।

और यह कभी न भूलें कि त्रुटि कोड का उद्देश्य हेल्प डेस्क के लिए जीवन को आसान बनाना है ।

Comments

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

— xdhmoore

मुझे लगता है कि सहसंबंध आईडी के भीतर त्रुटि कोड को शामिल करने का एक तरीका है ताकि यह मदद डेस्क के लिए मानव-पढ़ने योग्य त्रुटि कोड के रूप में और डेवलपर्स के लिए त्रुटि उदाहरण आईडी के रूप में सेवा कर सके।

— xdhmoore

मेरा पैटर्न बहुत समान है। लेकिन "ई" के बजाय, मैंने ऐप-पार्ट की कमी को जोड़ा। हमारे प्रलेखन-फ्रेमवर्क में उदा है, Doc1234जबकि मुख्य-ऐप में हो सकता है IrS1234। इसलिए मेरे उपयोगकर्ताओं की मदद करने के साथ मेरे हेल्पडेस्क-सहकर्मी बहुत तेज़ हैं।

— मथायस बर्गर

Answer 2

आपको पहले उन क्षेत्रों को अलग करना होगा जहां त्रुटियां हो सकती हैं, और उपयोगकर्ता-दृश्यमान हैं। फिर आप उन्हें दस्तावेज कर सकते हैं। यह इत्ना आसान है।

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

मैं तब 2-चरण दृष्टिकोण की सिफारिश करूंगा। पहले लॉग इन करना है, बहुत सारे और बहुत से लॉग इन करना है।

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

वेब सर्वर और आपके http त्रुटि कोड उदाहरण के लिए समान दृष्टिकोण का उपयोग किया जाता है। यदि उपयोगकर्ता 404 देखता है, और समर्थन करने के लिए रिपोर्ट करता है, तो वे लॉग में देखेंगे कि क्या चल रहा है, कौन से पेज का दौरा किया गया था, कब, और किसी अन्य जानकारी को चमकाएगा, जहां से वे कभी-कभी समझ में आते हैं , DB, नेटवर्क या अनुप्रयोग में हो।

Answer 3

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

Comments

मैं उस व्यक्ति की सराहना करूँगा जिसने 1 से 0 तक इस उत्तर को कम से कम एक कारण बताया ...

— स्टीफन बिलिएट

मुझे नीचा नहीं दिखाया गया (यह मायने नहीं रखता है कि इस पर काबू पाएं), लेकिन मुझे लगता है कि भाषा में वापसी मूल्यों के लिए मौजूदा समर्थन भी है।

— gbjbaanb

यह मेरे लिए मायने रखता है; अगर मैं गलत हूं, तो मैं जानना चाहूंगा ताकि मैं सीख सकूं: -आप का क्या मतलब है, रिटर्न वैल्यू के लिए मौजूदा समर्थन? क्या आपको त्रुटि कोड से सामान्य रिटर्न मान को अलग करने के लिए प्लंबिंग नहीं लिखना होगा? किसी सिस्टम की सीमा पर एक त्रुटि कोड के लिए अपवाद का अनुवाद करना एक बात है, लेकिन आपके सिस्टम के अंदर उन्हें जकड़ना कुछ ऐसा है जिसके खिलाफ आपको सलाह दी जाती है। मेरा मानना ​​है कि व्यावहारिक प्रोग्रामर इस तरह के सामान का उल्लेख करता है।

— स्टीफन बिलिएट

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

— gbjbaanb

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

— कोडिज़्म