RxJava2 में मानक त्रुटि हैंडलर या क्यों RxJava आवेदन दुर्घटनाओं का कारण बनता है भले ही onError लागू हो

लेख RxJava2 संस्करण 2.0.6 और बाद में UndeliverableException पर चर्चा करेगा। यदि कोई टकरा गया है और उसका पता नहीं लगा सकता है, या उसने इस समस्या के बारे में बिल्कुल नहीं सुना है - मैं एक बिल्ली के लिए पूछता हूं। उन्होंने RxJava1 से RxJava1 में संक्रमण के बाद production में समस्याओं के अनुवाद को प्रेरित किया। मूल 28 दिसंबर, 2017 को लिखा गया था, लेकिन देर से कभी भी पता लगाना बेहतर है।
जब हम RxJava उपयोग करते हैं तो हम सभी अच्छे डेवलपर होते हैं और onError में त्रुटियों को RxJava । इसका मतलब है कि हमने खुद को एप्लिकेशन क्रैश से बचाया है, है ना?

नहीं, सच नहीं है।

नीचे हम ऐसे कुछ उदाहरणों को RxJava जिनमें RxJava कारण एप्लिकेशन RxJava हो जाएगा, भले ही onError सही तरीके से लागू किया गया हो।

RxJava में बुनियादी त्रुटि हैंडलर

RxJava बेस त्रुटि हैंडलर के रूप में RxJava का उपयोग करता है। यह सभी त्रुटियों को संभालता है जो ग्राहक तक नहीं पहुंचाई जा सकती हैं। डिफ़ॉल्ट रूप से, सभी त्रुटियां इसे भेजी जाती हैं, इसलिए महत्वपूर्ण एप्लिकेशन क्रैश हो सकता है।
2.0.6 इस व्यवहार का वर्णन करते हैं:

2.x डिजाइन के लक्ष्यों में से एक खो त्रुटियों की कमी है। कभी-कभी स्रोत समाप्त होने से पहले एक अनुक्रम समाप्त हो जाता है या रद्द कर दिया जाता है। इस स्थिति में, त्रुटि कहीं नहीं है और इसे RxJavaPlugins.onError भेजा जाता है

यदि RxJava में एक मूल त्रुटि हैंडलर नहीं है, तो ऐसी त्रुटियां हमसे छिपी होंगी और डेवलपर्स कोड में संभावित समस्याओं के बारे में अंधेरे में होंगे।

संस्करण 2.0.6 साथ शुरू, RxJavaPlugins.onError होशियार होने की कोशिश करता है और लाइब्रेरी / कार्यान्वयन त्रुटियों और स्थितियों को साझा करता है जब कोई त्रुटि वितरित नहीं की जा सकती। "बग" की श्रेणी के लिए सौंपी गई त्रुटियों को वे कहते हैं, जबकि बाकी UndeliverableException में लिपटे होते हैं और फिर बुलाए जाते हैं। आप यह सब तर्क यहाँ देख सकते हैं ( onError और isBug )।

RxJava में मुख्य गलतियों में से एक newbies है OnErrorNotImplementedException । यह त्रुटि तब होती है जब onError त्रुटि का कारण बनता है और ग्राहक में onError विधि लागू नहीं होती है। यह त्रुटि एक त्रुटि का एक उदाहरण है कि बुनियादी त्रुटि हैंडलर के लिए RxJava एक "बग" है और एक UndeliverableException में नहीं बदल जाता है।

UndeliverableException

चूंकि "बग" से संबंधित त्रुटियां ठीक करना आसान है, इसलिए हम उन पर ध्यान नहीं देंगे। RxJava एक RxJava में जो त्रुटियां हैं, वे अधिक दिलचस्प हैं, क्योंकि यह हमेशा स्पष्ट नहीं हो सकता है कि त्रुटि को onError क्यों नहीं पहुंचाया जा सकता है।

जिन मामलों में ऐसा हो सकता है, वे इस बात पर निर्भर करते हैं कि स्रोत और ग्राहक विशेष रूप से क्या करते हैं। हम नीचे दिए गए उदाहरणों पर विचार करेंगे, लेकिन सामान्य तौर पर हम यह कह सकते हैं कि यदि कोई सक्रिय सब्सक्राइबर नहीं है, तो ऐसी त्रुटि तब होती है, जब त्रुटि वितरित की जा सकती है।

उदाहरण के साथ zipWith ()

पहला विकल्प जिसमें आप एक UndeliverableException उठा सकते हैं, वह zipWith ।

 val observable1 = Observable.error<Int>(Exception()) val observable2 = Observable.error<Int>(Exception()) val zipper = BiFunction<Int, Int, String> { one, two -> "$one - $two" } observable1.zipWith(observable2, zipper) .subscribe( { System.out.println(it) }, { it.printStackTrace() } ) 

हम दो स्रोतों को एक साथ जोड़ते हैं, जिनमें से प्रत्येक एक त्रुटि का कारण बनता है। हम क्या उम्मीद करते हैं? हम मान सकते हैं कि onError को दो बार कहा जाएगा, लेकिन यह Reactive streams विनिर्देश का विरोधाभास करता है ।

टर्मिनल इवेंट ( onError , onCompelete ) पर सिंगल कॉल के बाद, यह आवश्यक है कि कोई और कॉल न की जाए

यह पता चला है कि onError सिंगल कॉल के साथ onError दूसरी कॉल अब संभव नहीं है। स्रोत में दूसरी त्रुटि होने पर क्या होता है? इसे RxJavaPlugins.onError तक RxJavaPlugins.onError ।

इस स्थिति में आने का एक आसान तरीका है कि नेटवर्क कॉल्स को मिलाने के लिए zip का इस्तेमाल किया जाए (उदाहरण के लिए, दो Retrofit कॉल Observable लौटाते हुए)। यदि दोनों कॉल में कोई त्रुटि होती है (उदाहरण के लिए, कोई इंटरनेट कनेक्शन नहीं है), तो दोनों स्रोत त्रुटियों का कारण onError , जिनमें से पहला onError कार्यान्वयन में onError , और दूसरा आधार त्रुटि हैंडलर ( RxJavaPlugins.onError ) को वितरित किया जाएगा।

ग्राहकों के बिना ConnectableObservable उदाहरण

ConnectableObservable भी एक UndeliverableException बढ़ा सकता है। यह याद रखने योग्य है कि ConnectableObservable सक्रिय ग्राहकों की उपस्थिति की परवाह किए बिना घटनाओं को उठाता है, बस connect() विधि को कॉल करें। यदि कोई ग्राहक नहीं होने पर ConnectableObservable में कोई त्रुटि होती है, तो इसे आधार त्रुटि हैंडलर तक पहुंचाया जाएगा।

यहाँ एक बहुत ही निर्दोष उदाहरण है कि इस तरह की त्रुटि हो सकती है:

 someApi.retrofitCall() //     Retrofit .publish() .connect() 

यदि someApi.retrofitCall() एक त्रुटि का कारण बनता है (उदाहरण के लिए, कोई इंटरनेट कनेक्शन नहीं है), तो अनुप्रयोग क्रैश हो जाएगा क्योंकि नेटवर्क त्रुटि RxJava आधार त्रुटि RxJava को वितरित की RxJava ।

यह उदाहरण काल्पनिक लगता है, लेकिन ऐसी स्थिति में ConnectableObservable बहुत आसान है जहां ConnectableObservable अभी भी जुड़ा हुआ है, लेकिन इसके कोई ग्राहक नहीं हैं। एक एपीआई कॉल करते समय autoConnect() का उपयोग करते समय मैं इस पर आया था। autoConnect() स्वचालित रूप से autoConnect() अक्षम नहीं करता है। मैंने Activity के onStop विधि में सदस्यता समाप्त कर onStop , लेकिन Activity के विनाश के बाद नेटवर्क कॉल का परिणाम वापस आ गया और एप्लिकेशन onStop साथ UndeliverableException ।

हैंडलिंग में त्रुटि

तो इन त्रुटियों का क्या करें?

पहला चरण उन त्रुटियों को देखना है जो उत्पन्न होती हैं और यह निर्धारित करने का प्रयास करती हैं कि उनके कारण क्या हैं। आदर्श रूप से, यदि आप RxJavaPlugins.onError को RxJavaPlugins.onError करने से त्रुटि को रोकने के लिए इसके स्रोत पर समस्या को ठीक कर सकते हैं।

zipWith उदाहरण के लिए समाधान एक या दोनों स्रोतों को लेना है और उनमें त्रुटियों को पकड़ने के लिए तरीकों में से एक को लागू करना है। उदाहरण के लिए, आप त्रुटि के बजाय डिफ़ॉल्ट मान को पारित करने के लिए onErrorReturn का उपयोग कर सकते हैं।

ConnectableObservable उदाहरण को ठीक करने के लिए सरल है - बस यह सुनिश्चित करें कि जब आप अंतिम ग्राहक सदस्यता समाप्त करते हैं तो आप Observable डिस्कनेक्ट कर देते हैं। autoConnect() , उदाहरण के लिए, एक अतिभारित कार्यान्वयन है जो एक फ़ंक्शन लेता है जो कनेक्शन समय को पकड़ता है ( अधिक से अधिक यहां देखा जा सकता है )।

समस्या को हल करने का दूसरा तरीका आधार त्रुटि हैंडलर को अपने साथ बदलना है। RxJavaPlugins.setErrorHandler(Consumer<Throwable>) विधि आपको इसमें मदद करेगी। यदि यह वह समाधान है जो आपके लिए सही है, तो आप RxJavaPlugins.onError भेजी गई सभी त्रुटियों को पकड़ सकते हैं और जैसा कि आप फिट देखते हैं, उन्हें संभाल सकते हैं। यह समाधान काफी जटिल हो सकता है - याद रखें कि RxJavaPlugins.onError एप्लिकेशन में सभी RxJava धाराओं से त्रुटियां प्राप्त करता है।

यदि आप मैन्युअल रूप से अपना emitter.tryOnError() बनाते हैं, तो आप emitter.tryOnError() बजाय emitter.tryOnError() कॉल कर सकते हैं। यह विधि तभी त्रुटि की रिपोर्ट करती है जब धारा समाप्त नहीं होती है और उसके सदस्य होते हैं। याद रखें कि यह विधि प्रयोगात्मक है।

इस लेख का नैतिक यह है कि आप यह सुनिश्चित नहीं कर सकते कि RxJava के साथ काम करते समय कोई त्रुटि नहीं है यदि आप बस सब्सक्राइबर्स में onError को लागू onError । आपको उन स्थितियों के बारे में पता होना चाहिए जिनमें ग्राहक के लिए त्रुटियां उपलब्ध नहीं हो सकती हैं, और सुनिश्चित करें कि इन स्थितियों को नियंत्रित किया जाता है।