त्रुटि कोड का उपयोग करना उचित है?

Question

अपवाद वस्तुओं (जावा, सी #) का समर्थन करने वाली भाषाओं में, error codes का उपयोग करने के लिए उपयुक्त कब है? क्या सामान्य एंटरप्राइज़ अनुप्रयोगों में कभी भी त्रुटि कोड का उपयोग उचित है?

कई प्रसिद्ध सॉफ्टवेयर सिस्टम त्रुटि कोड (और एक संबंधित त्रुटि कोड संदर्भ) को नियोजित करते हैं। कुछ उदाहरणों में ऑपरेटिंग सिस्टम (विंडोज), डेटाबेस (ओरेकल, डीबी 2), और मध्यम-वेयर उत्पाद (वेबलॉगिक, वेबस्पियर) शामिल हैं। त्रुटि कोड क्या लाभ प्रदान करते हैं? त्रुटि कोड का उपयोग करने के नुकसान क्या हैं?

Answer 1

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

सरल चीजों के लिए जो हमेशा कोड के बिना मानव-संचालित त्रुटि संदेश होंगे ठीक है। आप इसे त्रुटि कोड दिए बिना "फ़ाइल नहीं मिली" कह सकते हैं। हालांकि, अगर यह दूसरे छोर पर एक और कंप्यूटर हो सकता है तो आपको इसके अलावा त्रुटि कोड देना चाहिए। जब आप इसे "फ़ाइल <x> नहीं मिला" में बदलते हैं तो आप अन्य सिस्टम को तोड़ना नहीं चाहते हैं।

Answer 2

त्रुटि कोड पुराने स्कूल हैं। वे बिल्कुल कम मूल्य के हैं।

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

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

अपवादों की एक व्यापक तकनीक होने से पहले मैंने कंप्यूटर प्रोग्राम करना सीखा। मैं हूं इसलिए खुश हैं कि हमें इसके बजाय अपवाद मिला!

Answer 3

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

उस ने कहा, मैं उस समय .NET के लिए नौसिखिया था, और तब से कभी भी त्रुटि कोड का उपयोग नहीं किया है।

एक विंडोज़ व्यक्ति के रूप में एक साइड नोट के रूप में, एक त्रुटि कोड में प्लॉप करने में सक्षम होना अच्छा लगता है और एक KB आलेख के साथ आना अच्छा होता है, इसलिए एक अच्छा कोड अच्छा दस्तावेज के साथ संयुक्त त्रुटि और इसे खोजने की क्षमता = अच्छी भावनाएं अपने उपयोगकर्ताओं से

Answer 4

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

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

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

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

Answer 5

वेब सेवा इंटरफेस के लिए बहुत आम है। वर्णन के साथ कोड वापस करने के लिए यह बहुत आसान और मानक है।

मैं मानता हूँ कि परिदृश्यों के सबसे पुराने स्कूल है के लिए

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

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

Answer 6

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

एफडब्ल्यूआईडब्ल्यू, सी ++ अपवाद वस्तुओं का भी समर्थन करता है। मुझे नहीं लगता कि सी ++ अंततः कीवर्ड का समर्थन करता है (हालांकि नए सी ++ व्हाट्सवर बस हो सकते हैं), लेकिन सी ++ में आपको कैच हैंडलर के अंदर लौटने जैसी चीज़ों से बचना होगा।

Answer 7

मैं अतिप्रवाह ढेर करने के लिए एक नौसिखिया लेकिन ...

मुझे विश्वास है कि त्रुटि कोड एक को सुधारने के लिए शामिल होने के लिए या प्रयोग की जाने वाली गलत स्थितियों तरह की एक अंतिम-उपयोगकर्ता की आवश्यकता है कि के साथ काम करने के लिए उपयोगी होते हैं हूँ परिस्थिति। यदि आपका कोड किसी अन्य डेवलपर द्वारा बनाए रखा जाना है तो अपवाद जाने का तरीका है।

• वातावरण में

  कि आपका ऐप्लिकेशन आपके एप्लिकेशन और कुछ अन्य संस्था (वेब ​​सर्वर, डाटाबेस, सॉकेट, आदि) के बीच संचार के साथ

• चल रहा है: हालांकि, एक स्थिति में जहाँ वहाँ एक समस्या है

• कि कोई उपकरण या डिवाइस ड्राइवर को इंगित करता है (शायद हार्डवेयर विफलता?)

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

फिर से डेवलपर/इंजीनियर स्तर पर जो स्रोत कोड (पारंपरिक डिबगिंग और परीक्षण तकनीकों) को स्पर्श करने और इसे संशोधित करने में सक्षम होंगे, अपवादों का उपयोग करें।

आशा है कि इससे मदद मिलती है ...

--jqpdev

Answer 8

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

HTTP परिणाम कोड इस प्रकार के व्यवहार के एक अच्छे उदाहरण के रूप में लें। "200" का मतलब है खुश, "300" किसी भी तरह से जा सकता है, "400" या "500" का मतलब है कि बाहर निकलना शुरू हो गया है।

Answer 9

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

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

अपवाद तंत्र इसे संभालने का एक शानदार तरीका है "यह एक आपात स्थिति है, हमें वापस जाना होगा कोड जब तक समस्या से निपटने के लिए कुछ भी कर सकते हैं "। त्रुटि कोड इस से कम हैं।

Answer 10

त्रुटि कोड यदि आप उन्हें उपयोगकर्ता को भेजना चाहते हैं तो हैं। यदि नहीं, तो अपवाद का उपयोग करें।