क्या वेब सेवाएं अपवाद फेंक सकती हैं या परिणाम ऑब्जेक्ट्स

मुझे यकीन नहीं है कि मैं पूरी तरह से खुश हूं कि वेब सेवाओं में अपवाद फेंकना एक अच्छा विचार है। अगर मैं स्टैक ट्रेस के लिए नहीं था तो मुझे इतना बुरा नहीं लगेगा। यह ऐसा कुछ नहीं है जो मैं नहीं चाहता था।क्या वेब सेवाएं अपवाद फेंक सकती हैं या परिणाम ऑब्जेक्ट्स

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

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

क्या किसी के पास कोई बेहतर समाधान है?

संपादित

BTW मैं ASMX वेब सेवाओं का उपयोग कर रहा है, जहां customErrors मोड़ पर एक विकल्प नहीं है।

स्रोत

2009-06-19 Ryan Tomlinson

असल में, मेरा मानना है कि अपवाद विवरण को हटाने का तरीका web.config में customErrors टैग के साथ खेलना है। इस पर विश्वास करें या नहीं। –

@ जॉन: हाँ, जो मैं यहां कह रहा हूं। दुर्भाग्य से यह मेरे लिए एक विकल्प नहीं है। अन्यथा यह मेरे लिए एक बहुत ही आसान समस्या होगी :( –

आप किस स्टैक ट्रेस के बारे में बात कर रहे हैं? क्या आपने यह कोशिश की है?

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

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

स्रोत

2009-06-19 17:39:22

संक्षेप में मैं उपयोगकर्ता को सूचित करना चाहता हूं कि उपयोगकर्ता त्रुटि कोड और desciption (मेरे चयन का) के साथ एक अपवाद है। मुझे लगता है कि अपवाद हैंडलिंग के बीच एक अर्थपूर्ण भिन्न है वेब सेवाओं और एप्लिकेशन आर्किटेक्चर के लिए, लेकिन मुझे इस बात के बारे में अनिश्चितता है कि उन्हें अलग-अलग व्यवहार करना चाहिए या नहीं। जब आप कोई गलती करते हैं तो कोड में परिणाम ऑब्जेक्ट नहीं लौटाएंगे। क्या वेब सेवाओं को कोई अलग होना चाहिए। नहीं (जैसा कि आप इंगित करते हैं)। मुझे लगता है कि मेरा सवाल यह है कि मैं अपवाद विवरण को कैसे सारणीबद्ध करता हूं? –

एसओएपी दोषों पर पढ़ें। यह क्लाइंट को मनमाने ढंग से विस्तार करने का मानक तरीका है। एएसएमएक्स वेब सेवाओं में, आपको उन्हें "हाथ से" विवरण में वापस करना होगा सोपएक्सप्शन इंस्टेंस की संपत्ति, लेकिन अगर आपको एएसएमएक्स के साथ रहना है तो यह सही तरीका है। बेशक बेहतर तरीका डब्ल्यूसीएफ का उपयोग करना है। इसके अलावा, उपयोगकर्ताओं को अपवादों के बारे में सूचित करने के बारे में मत सोचो। अपवाद एक हैं कार्यान्वयन विस्तार। आप उन्हें एक गलती के बारे में सूचित कर रहे हैं। –

यह वह नहीं है जो मैं देखता हूं। मेरी एएसएमएक्स वेब सेवाएं सभी डिफ़ॉल्ट सेटिंग्स के तहत स्टैक निशान लौटाती हैं, और यह मुझे पागल बनाती है। और जब एक-दूसरे को बुलाए जाने वाली सेवाओं की एक श्रृंखला होती है, और श्रृंखला में आखिरी बार फेंकता है, तो ग्राहक को सभी भाग लेने वाली सेवाओं से एक मोहक स्टैक ट्रेस प्राप्त होता है ('सोपएक्सप्शन' के रूप में 'संदेश' संपत्ति जिसमें स्टैक होता है समेकित पाठ के रूप में पता लगाएं)। यह भयानक है और मुझे नहीं पता कि इसे कैसे बंद किया जाए। – GSerg

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

इस परिदृश्य का कौन सा हिस्सा आप सोच रहे हैं?

स्रोत

2009-06-19 17:40:30 Bruce

@ ब्रूस: बेजोड़ अपवादों का अनुवाद दोषों में किया जाएगा।कुछ परिस्थितियों में, उन विवरणों को छोड़कर शामिल होंगे। –

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

@ रयान: web.config में customeError टैग के सभी संयोजनों के माध्यम से काम करें। मेरा मानना है कि उनमें से एक स्टैक निशान बंद कर देता है। –

मुझे लगता है कि अपवाद फेंकना सामान्य रूप से एक बेहतर डिजाइन पैटर्न है जिसके परिणामस्वरूप वापसी होती है। मुझे लगता है कि आप क्या करना है वह यह है कि अपने वेब सेवाओं वेब सेवा के रूप में सामने आ रहा प्रत्येक विधि के लिए निम्न पैटर्न लगाने से स्टैक ट्रेस को छिपाने के लिए अंदर:

public void MyWebServiceMethod() {
try
{
///Do something that may cause an error 
} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

या आप कर सकते हैं भी

catch(Exception ex) { throw ex; }

आप तो एक अपवाद दोबारा फेंक दो, आप अपनी वेब सेवाओं के ग्राहकों से मूल स्टैक ट्रेस छुपाएंगे।

स्रोत

2009-06-19 17:46:02

@ बोगदान: सबसे पहले, एमएस ने .NET 1.1 में एप्लिकेशन अपवाद मार्ग को वापस कर दिया है। इसके बजाए "अपवाद" का प्रयोग करें। दूसरा, मुझे लगता है कि ओपी बिल्कुल कोई स्टैक ट्रेस नहीं चाहता है। –

@ जॉन, एप्लिकेशन अपवाद द्वारा मेरा मतलब कोई कस्टम अपवाद था। ठीक है, मान लें कि यह MyWebServiceException या ऐसा कुछ होना चाहिए। इसके अलावा, वास्तव में इसे बहिष्कृत नहीं किया गया है, और सिस्टम जैसे अपवाद। थ्रेडिंग। WaitHandleCannotBeOpenedException अभी भी इसका उत्तराधिकारी है। एमएस केवल इतना कहता है कि वे नहीं सोचते कि यह बहुत मूल्यवान है, लेकिन फिर भी आप अपने अपवादों के लिए बेस क्लास के रूप में उपयोग करते हैं, स्वाभाविक रूप से आपकी पसंद है, जिसे कभी-कभी संविधानों द्वारा कोडिंग द्वारा निर्धारित किया जाता है जिसे आपको वर्तमान परियोजना में पालन करना चाहिए। –

इस तथ्य को न दें कि आप एक वेब सेवा में हैं इस मुद्दे को भ्रमित करें। यह सिर्फ एक कार्यान्वयन विस्तार है।

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

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

स्रोत

2009-06-19 17:50:12 Maladon

@ मालाडॉन: परत सीमाओं को छोड़कर यह एक अच्छा जवाब है। आम तौर पर, रणनीतियां परत सीमाओं पर बदलती हैं, खासकर सेवा परत पर। विशेष रूप से, डब्ल्यूसीएफ के लिए, अपरिपक्व "ए" को पकड़ने के लिए एक परत सीमा एक अच्छी जगह होगी और इसे FaultException के साथ दोबारा दोहराएगी, जो एसओएपी गलती AFault भेज देगा। कोई स्टैक ट्रेस नहीं, बीटीडब्ल्यू। एएसएमएक्स दोषों का सही ढंग से समर्थन नहीं करता है; इसका उपयोग करने के लिए एक और कारण है। –

एक दृष्टिकोण सिस्टम और व्यावसायिक त्रुटियों को अलग करना है। (सिस्टम त्रुटि: उदा। विकृत अनुरोध, उपयोगकर्ता-अधिकृत नहीं, आदि; व्यवसाय त्रुटि: उदाहरण के लिए विधि UpdateCars किसी त्रुटि में परिणाम देता है, उपयोगकर्ता के पास कोई कार नहीं है)।

किसी व्यवसाय त्रुटि के मामले में, एक त्रुटि ऑब्जेक्ट वाले प्रतिक्रिया ऑब्जेक्ट को वापस करें; सिस्टम त्रुटि के मामले में, अपवाद फेंक दें।

स्रोत

2009-06-19 17:52:44 azheglov

एसओएपी स्पेक गलतियों के लिए त्रुटि की स्थिति लौटने के लिए प्रदान करता है, और उनका उपयोग किया जाना चाहिए। अन्यथा, आपके ग्राहक वापस लौटने वाले मूल्यों की जांच करने के लिए याद रखने के लिए वापस आ जाएंगे, और दोषों के अपने प्लेटफ़ॉर्म-विशिष्ट अनुवाद का उपयोग करने में सक्षम नहीं होंगे। –

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

स्रोत

2009-06-19 18:25:31

@ जेम्स: मानक के साथ चिपके रहना बेहतर हो सकता है। यह दोषों के लिए प्रदान करता है, तो उनका उपयोग क्यों नहीं करें? इसके अलावा, डेवलपर्स त्रुटि कोड जांचना भूल जाते हैं। यही कारण है कि अपवादों का आविष्कार किया गया था, और एसओएपी दोष अपवादों का वेब सेवा संस्करण हैं। –

जैसा कि जॉन कहते हैं, और मैं सहमत हूं, गलती को सूचित करने के लिए अपवाद हैं। अपवादों को एसओएपी गलती में क्रमबद्ध किया जाएगा। परिणामस्वरूप एक त्रुटि कोड लौटने से प्रोटोकॉल में बहुत अच्छी तरह फिट नहीं होता है। नीचे देखें: http://msdn.microsoft.com/en-us/library/ds492xtk(VS.85).aspx –

क्या वेब सेवाएं अपवाद फेंक सकती हैं या परिणाम ऑब्जेक्ट्स

उत्तर

संबंधित मुद्दे