अपवाद या त्रुटि कोड


12

हम एक वेब सेवा (SOAP, .Net) का निर्माण कर रहे हैं, जिसमें (ज्यादातर) देशी ग्राहकों (विंडोज़, C ++) से बात की जाएगी और हम सोच रहे हैं कि क्लाइंट को त्रुटियों को संप्रेषित करने का सबसे अच्छा तरीका क्या है (जैसे SomeBadHappened जैसे लॉगिन सेवा उपलब्ध नहीं है। या ऐसा कुछ नहीं है जो उपयोगकर्ता को नहीं मिला) और ऊपर से करने के लिए क्लाइंट को फेंकने या किसी प्रकार के त्रुटि कोड मॉडल का उपयोग करने के बीच निर्णय लेने में सक्षम नहीं है।

आप क्लाइंट साइड पर हैंडलिंग पर क्या पसंद करेंगे: त्रुटि कोड प्राप्त करना या सर्वरफॉल्ट अपवाद को हैंडल करना जिसमें त्रुटि का कारण होता है?
1) हम अपवाद क्यों सोच रहे हैं: क्योंकि यह सर्वर साइड कोड को बहुत अधिक समान बना देगा
2) हम त्रुटि कोड क्यों सोच रहे हैं: क्योंकि हमें लगता है कि यह ग्राहक पक्ष के परिप्रेक्ष्य से अधिक समझ में आता है।

यदि 2) वास्तव में सच है तो हम अपवादों की तुलना में त्रुटि कोड के लिए जाना चाहेंगे? क्या यहाँ भी ऐसा ही है?

इसके अलावा, यदि हम मूल ग्राहकों के बजाय प्रबंधित ग्राहकों से बात कर रहे हों तो क्या इसका उत्तर बदल जाएगा?


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

यह मदद कर सकता
गुलशन

जवाबों:


8

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

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

Microsoft पैटर्न और अभ्यास पर मार्गदर्शन की जाँच करें ।


धन्यवाद यह अच्छा लगता है। क्या आप मुझे वहां पृष्ठ के भीतर एक अधिक विशिष्ट लिंक दे सकते हैं।
अमित वाधवा

इसके अलावा क्या व्यावसायिक स्तर की त्रुटियों के बारे में जैसे UserNotFound आदि को भी अपवाद के रूप में संभाला जाना चाहिए
अमित वाधवा

पिछले परियोजनाओं में हमने कभी भी एसओएपी में कोड या दोषों में अपवादों का उपयोग नहीं किया, ताकि असफलता के वैध / अपेक्षित तरीकों का संचार किया जा सके। हमने त्रुटि कोड का उपयोग किया और उन्हें ग्राहक के पास छोड़ दिया कि वे उनके साथ क्या करें। उपयोगकर्ता नहीं मिला वास्तव में एक त्रुटि / अपवाद नहीं है, यह संभवतः एक स्थिति कोड होना चाहिए।
मृलेन

4

मैंने हाल ही में जावा 6 पुस्तकालयों के साथ एक वेब सेवा की है, जो कॉल करने वाले को वापस अपवाद की सूचना दे सकता है (मैंने देखा नहीं है कि यह कैसे स्वचालित रूप से किया जाता है)।

क्लाइंट के पास त्रुटि रिपोर्ट में एक स्टैक ट्रेस प्रदान करने की क्षमता डेवलपर के लिए बहुत उपयोगी है (एक अनुमानित टाइमस्टैम्प प्राप्त करने के लिए विरोध किया गया है और फिर आपको इसे लॉग करने के लिए होता है)।

इसलिए, डेवलपर्स के दृष्टिकोण से देखा जाए, तो अपवाद का उपयोग करें।


1
मैं इस बात से सहमत हूं कि यह डॉगफूड और बीटा में उपयोगी हो सकता है, लेकिन क्या आप वास्तव में इवेंट लॉग्स में स्टैक के निशान या वास्तविक दुनिया के उपयोग में लॉग फाइल करना चाहते हैं (और निश्चित रूप से आपकी आवश्यकता से अधिक सेवा के बारे में अधिक जानकारी का खुलासा करना चाहते हैं / प्रक्रिया में हैं) )
अमित वाधवा

2
@Amit, इस पर मेरा विश्वास करो: यदि आप उत्पादन में स्टैक ट्रेस देने वाली स्थिति से टकराते हैं, तो आप स्टैक ट्रेस का पता लगा सकते हैं!

1
क्लाइंट पक्ष पर स्टैक ट्रेस पर लाभ क्या है, हम क्लाइंट पर इसे पारित करने से पहले सर्वर साइड पर सभी अपवादों को निश्चित रूप से लॉग करेंगे।
अमित वाधवा

इसके अलावा क्या व्यावसायिक स्तर की त्रुटियों के बारे में जैसे UserNotFound आदि को भी अपवाद के रूप में संभाला जाना चाहिए
अमित वाधवा

-2

यदि यह एक वेब सेवा है, तो आप सर्वर को अपवाद को फेंकने का कारण नहीं बन सकते हैं जो क्लाइंट द्वारा पकड़ा जाएगा। इंटरफ़ेस पर, आपके सर्वर को मूल रूप से किसी प्रकार का त्रुटि कोड वापस करना पड़ता है, भले ही यह एक स्ट्रिंग है जो कहता है An exception occurred. Type %s, message %s, stack trace %s

ग्राहक पक्ष के लिए, आप अपना प्रतिक्रिया पठन कोड देख सकते हैं कि प्रतिक्रिया में यह देखने के लिए कि क्या इसमें कोई त्रुटि है और ग्राहक पक्ष पर एक अपवाद बढ़ाएं। यह एक बहुत अच्छा तरीका है इसे करने के लिए, अच्छी अपवाद हैंडलिंग वाली भाषाओं में। C ++, हालांकि, अच्छा अपवाद सौंपने नहीं है, और यह संभव है कि C ++ अपवादों से यथासंभव दूर रहें। यदि आप एक बेहतर भाषा का उपयोग नहीं कर सकते हैं, तो बस त्रुटि कोड से चिपके रहें।


मुझे लगता है कि बिना किसी अपवाद के क्लाइंट के लिए सर्वरफॉल्ट के रूप में जाना जाएगा
अमित वाधवा

3
सी ++, या सी ++ अपवादों के साथ कुछ भी गलत नहीं है। कुछ परियोजनाओं के लिए C ++ के अलावा किसी अन्य भाषा का उपयोग करने के बहुत सारे कारण हैं, लेकिन अपवाद हैंडलिंग उनमें से एक नहीं है।
कीथबी

इतना ही नहीं यह सुरक्षा सर्वोत्तम प्रथाओं के खिलाफ है: ग्राहक को आपके सर्वर के स्टैक ट्रेस के साथ वास्तव में क्या करना चाहिए? इसे प्रिंट करें और आप को भेजें? ईमेल के रूप में भेजें? चिकनाई कागज के लिए उपयोग करें?
18

@ जेन्सजी: यदि यह एक वेब सेवा है और वेबसाइट नहीं है , तो क्लाइंट को आपके लिए एक बग रिपोर्ट के रूप में ईमेल करने के लिए पर्याप्त पेशेवर होना चाहिए।
मेसन व्हीलर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.