सिल्वरलाइट में डब्ल्यूसीएफ अपवाद को पकड़ने का सबसे अच्छा तरीका?

Question

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

• क्योंकि यह एक अतुल्यकालिक कॉल है, मैं लपेट नहीं कर सकता मेरी आज़माएं/कैच ब्लॉक के साथ कॉल शुरू करते हैं और यह एक अपवाद के बाद कार्यक्रम उस बिंदु से पर ले जाया गया है होता है कि लेने के लिए है।

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

• मैं अपने कॉलबैक फ़ंक्शंस में कोशिश/पकड़ नहीं डाल सकता, क्योंकि अपवाद होने से पहले अपवाद होता है।

• मेरे App.xaml.cs में एक एप्लिकेशन_उंहैंडेड एक्सेप्शन फ़ंक्शन है, जो सभी अनचाहे अपवादों को कैप्चर करता है। मैं इसका इस्तेमाल कर सकता था, लेकिन ऐसा करने के लिए यह एक गन्दा तरीका लगता है। मैं वास्तव में अप्रत्याशित त्रुटियों (उर्फ बग) के लिए इस फ़ंक्शन को आरक्षित करता हूं और प्रत्येक परिस्थिति के लिए इस फ़ंक्शन में कोड के साथ समाप्त नहीं होता जिसे मैं किसी विशिष्ट तरीके से सौदा करना चाहता हूं।

क्या मुझे एक स्पष्ट समाधान याद आ रहा है? या मैं Application_UnhandledException का उपयोग कर अटक गया हूँ?

[संपादित करें]
जैसा कि नीचे बताया गया है, त्रुटि संपत्ति ठीक वही है जो मैं ढूंढ रहा था। मुझे लूप के लिए फेंकने वाला क्या है कि तथ्य यह है कि अपवाद फेंक दिया गया है और यह बेकार प्रतीत होता है, फिर भी निष्पादन जारी रखने में सक्षम है। यह Application_UnhandledException ईवेंट को ट्रिगर करता है और निष्पादन को तोड़ने के लिए VS2008 का कारण बनता है, लेकिन डीबगर में जारी रखने से निष्पादन जारी रहता है। यह वास्तव में एक समस्या नहीं है, यह सिर्फ अजीब लगता है।

Answer 1

मैं सेवा विधि पूर्ण ईवेंट हैंडलर में ईवेंट तर्क की त्रुटि प्रॉपर्टी की जांच करता हूं। मुझे इवेंट हैंडलर नहीं कहा जा रहा है के साथ कोई समस्या नहीं है। जिस स्थिति में सर्वर नीचे चला जाता है, कॉल में कुछ सेकंड लगते हैं तो त्रुटि संपत्ति में प्रोटोकॉल अपवाद के साथ वापस आ जाता है।

मान लीजिए कि आपने यह कोशिश की है और आपका कॉलबैक वास्तव में कभी नहीं बुलाया जाता है, तो आप जेनरेट प्रॉक्सी क्लास को अनुकूलित करने में देख सकते हैं। this article देखें।

Answer 2

मुझे a forum thread मिला जो इस बारे में बात कर रहा था, और यह उल्लेख करता है कि त्रुटि प्रॉपर्टी का उपयोग करना सबसे अच्छा अभ्यास है। इस सूत्र और मेरे स्वयं के अनुभवों के बीच, इस मैं क्या निष्कर्ष निकाल सकते हैं है:

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

• सिल्वरलाइट में, उत्पन्न प्रॉक्सी क्लास त्रुटि गुण सेट करता है, लेकिन अपवाद को पूरी तरह से संभाल नहीं करता है। अपवाद को डीबगर द्वारा उठाया जाता है, जो "प्रोटोकॉल अपवाद को उपयोगकर्ता कोड द्वारा अनचाहे" संदेश के साथ अपवाद बॉक्स को पॉप अप करता है। इस संदेश के बावजूद, अपवाद वास्तव में इसे अनुप्रयोग_उन्डहैंडेड अपवाद समारोह में नहीं लग रहा है।

मुझे उम्मीद है कि यह अंतिम रिलीज में ठीक होने वाली चीजों में से एक है।

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

Answer 3

आप asyn ग्राहक कॉलबैक पर के बारे में Application_UnhandledException भूल सकता है, कारण है कि:

Application_UnhandledException केवल अपवाद यूआई धागे पर गोली चलाई Application.UnhandledExceptions

इसका मतलब यह है द्वारा पकड़ा जा सकता है ... पर नहीं बुलाया डब्ल्यूसीएफ एसिंक कॉल के लिए सभी :-)।

चेक MSFT से विस्तृत प्रतिक्रिया

http://silverlight.net/forums/t/21828.aspx

हैलो, केवल यूआई धागे पर गोली चलाई अपवाद Application.UnhandledExceptions से पकड़ा जा सकता है। यह अन्य धागे से अपवाद नहीं पकड़ सकता है। आप इस मुद्दे को शूट करने में परेशानी के लिए कोशिश कर सकते हैं: विजुअल स्टूडियो में, डीबग मेनू से, अपवाद चुनें। फिर "सामान्य भाषा रनटाइम अपवाद" की जांच करें। जब भी एक अपवाद फेंक दिया जाता है तो यह डीबगर बंद कर देगा। लेकिन ध्यान दें कि कभी-कभी यह काफी परेशान हो सकता है क्योंकि भले ही कोई अपवाद पहले से पकड़ा गया हो। आप उन अपवादों को फ़िल्टर करने के लिए चेकबॉक्स का उपयोग कर सकते हैं जिन्हें आप पकड़ना चाहते हैं।

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

धन्यवाद

Braulio 

Answer 4

OOpps .... मेरी तरफ से

क्षमा गलत जवाब (अच्छी तरह से MSFT पुरुष लिखने जवाब सेवा कॉलबैक समान UI धागे पर कहा जाता है हिट नहीं किया),

- In development even detaching from the debugger, this method is never reached. 
- On the production environment yes. 

मेरा अनुमान है कुछ विसू के साथ संबंधित: बात

अधिक जानकारी है अल स्टूडियो विकल्प और अपवादों को अवरुद्ध करना।

अधिक जानकारी, इस सूत्र http://silverlight.net/forums/p/48613/186745.aspx#186745

काफी दिलचस्प विषय में।

Answer 5

मैं प्लंबर नहीं हूं, इसलिए मैंने अपनी खुद की डब्ल्यूसीएफ सेवा कक्षा बनाने का फैसला किया जो क्लास फ़ाइल "context.cs" की कुछ कार्यक्षमता को ओवरराइड करता है जो स्वचालित रूप से विजुअल स्टूडियो द्वारा जेनरेट किया जाता है, फिर मैंने अपनी कोशिश की/संचार त्रुटियों को पकड़ने के लिए ब्लॉक पकड़ो।

वर्ग मेरे द्वारा बनाए गए इस तरह दिखता है:

public class myWCFService : MyWCFServiceClient 
{ 

    protected override MyController.MyService.IMyWCFService CreateChannel() 
    { 
     return new MyWCFServiceClientChannel(this); 
    } 

} 

private class MyWCFServiceClientChannel : ChannelBase<MyController.MyService.IMyWCFService>, MyController.MyService.IMyWCFService 
{ 
    /// <summary> 
    /// Channel Constructor 
    /// </summary> 
    /// <param name="client"></param> 
    public MyWCFServiceClientChannel(System.ServiceModel.ClientBase<MyController.MyService.IMyWCFService> client) : 
    base(client) 
    { 
    } 
    /// <summary> 
    /// Begin Call To RegisterUser 
    /// </summary> 
    /// <param name="memberInformation"></param> 
    /// <param name="callback"></param> 
    /// <param name="asyncState"></param> 
    /// <returns></returns> 
    public System.IAsyncResult BeginRegisterUser(MyDataEntities.MembershipInformation memberInformation, System.AsyncCallback callback, object asyncState) 
    {    
     object[] _args = new object[1]; 
     _args[0] = memberInformation; 
     System.IAsyncResult _result = base.BeginInvoke("RegisterUser", _args, callback, asyncState); 
     return _result;    
    } 
    /// <summary> 
    /// Result from RegisterUser 
    /// </summary> 
    /// <param name="result"></param> 
    /// <returns></returns> 
    public MyDataEntities.MembershipInformation EndRegisterUser(System.IAsyncResult result) 
    { 
     try 
     { 
      object[] _args = new object[0]; 
      MyDataEntities.MembershipInformation _result = ((MyDataEntities.MembershipInformation)(base.EndInvoke("RegisterUser", _args, result))); 
      return _result; 
     } 
     catch (Exception ex) 
     { 
      MyDataEntities.MembershipInformation _result = new MyDataEntities.MembershipInformation(); 
      _result.ValidationInformation.HasErrors = true; 
      _result.ValidationInformation.Message = ex.Message; 
      return _result; 
     } 
    } 
} 

Answer 6

सिल्वरलाइट 3 विजुअल स्टूडियो डीबगर इन अपवादों ताकि अपवाद संचालक पकड़ता के साथ - साथ भ्रामक - कभी नहीं पहुँच जाता है।हालांकि, बिना डीबगर के चलते, अपवाद हैंडलर को अपेक्षित कहा जाता है। मुझे लगता है कि यह ठीक है जब तक कि किसी को इसके बारे में पता है। मैं मानता हूं कि मैंने अपने अपवाद को प्राप्त करने के लिए सिल्वरलाइट/डब्ल्यूसीएफ/ब्राउज़र के आंतरिक कार्यों में ड्रिल करने का प्रयास करने में कुछ घंटों बर्बाद कर दिए। वहां मत जाओ

Answer 7

कस्टम डब्ल्यूसीएफ प्रॉक्सी जनरेटर का उपयोग करना सिल्वर-light में एसिंक्रोनस अपवादों को संभालने का एक अच्छा समाधान है। स्रोत कोड डाउनलोड करने के लिए here पर क्लिक करें।

Answer 8

WP7 पर XNA के साथ, मैंने पाया कि मेरे पास अलग-अलग एसिंक एंड * फ़ंक्शननाम *() विधियों को मैन्युअल रूप से जोड़ने/पकड़ने के अलावा कोई विकल्प नहीं था; मैंने कोशिश की और कुछ भी नहीं किया जब सर्वर अनुपलब्ध था तो अनुप्रयोग विफलता & शटडाउन को रोक देगा। जब सेवा बदलती है तो यह वास्तव में इस कोड को मैन्युअल रूप से अपडेट करने के लिए एक असली ड्रैग है।

मुझे आश्चर्य है कि यह एक बड़ा मुद्दा नहीं है क्योंकि एक्सएनए का उपयोग करके WP7 पर इन अपवादों को पकड़ने का कोई अन्य तरीका प्रतीत नहीं होता है, लेकिन मुझे लगता है कि यह केवल इतना कहता है कि कितने (== नहीं) लोग किसी और चीज से ऐसा करने की कोशिश कर रहे हैं। अगर वे सिर्फ slsvcutil.exe सिंक विधियों को उत्पन्न करेंगे, तो हम आसानी से इन्हें अपने स्वयं के कार्यकर्ता थ्रेड के भीतर पकड़ सकते हैं, लेकिन दुर्भाग्यवश जेनरेट कोड थ्रेड पूल थ्रेड का उपयोग करता है जिसमें अपवादों को पकड़ने के लिए कोई साधन नहीं है।

Answer 9

इस स्थिति को संभालने के लिए TargetInvocationException का उपयोग करें। जब नेटवर्क डाउन हो या आपकी सेवा अनुपलब्ध हो तो यह अपवाद को पकड़ लेगा।