Swift.assert - रिलीज के बाद जीवन

आप अपने कोड में कितनी बार Swift.assert() उपयोग करते हैं? मैं ईमानदारी से इसे अक्सर उपयोग करता हूं (यदि यह बुरा अभ्यास है, तो कृपया टिप्पणियों में लिखें - यह बुरा क्यों है?)। मेरे कोड में आप अक्सर देख सकते हैं, उदाहरण के लिए, ऐसी कॉल:

 Swift.assert(Thread.isMainThread) 

बहुत समय पहले नहीं, मैंने फैसला किया कि इन कॉल्स से नतीजों को जारी रखना अच्छा होगा न केवल सिम्युलेटर / डिवाइस में एप्लिकेशन लॉन्च करने की रूपरेखा के भीतर, बल्कि वास्तविक उपयोगकर्ताओं के कार्यों से भी। वैसे, यहां हम Swift.precondition() , Swift.fatalError() , आदि के बारे में बात कर सकते हैं, हालांकि मैं उनसे बचने की कोशिश करता हूं। मैंने इस प्रकाशन में स्विफ्ट में अपरिवर्तनीय त्रुटियों के बारे में अधिक पढ़ा और यह बहुत जानकारीपूर्ण निकला।

इस बिंदु के करीब: कोड में मुझे लगभग 300 ऐसे कॉल मिले। उनमें से किसी ने भी सामान्य स्थानीय परीक्षण के दौरान काम नहीं किया, और इसने मुझे प्रसन्न किया। लेकिन मैंने सुझाव दिया कि उपयोगकर्ता कार्रवाई अभी भी कुछ कॉल को ट्रिगर कर सकती है।

उपयोगकर्ता के दृष्टिकोण से, क्रैश नहीं होना चाहिए (फिर से, मेरी राय)। चरम मामलों में, उपयोगकर्ता को समझना चाहिए कि कुछ परिदृश्य गलत हो गया है और विकास टीम पहले से ही इसे ठीक करने पर काम कर रही है। इसी तरह के अपवाद हमेशा मेरे द्वारा नियंत्रित किए जाते हैं, और उपयोगकर्ता के लिए यह सबसे हानिरहित रूप में प्रभावित हो सकता है। उदाहरण के लिए, सैकड़ों टेबल कोशिकाओं में से एक बस अदृश्य थी।

उपयोगकर्ता कम या ज्यादा के साथ सब कुछ स्पष्ट है। यह डेवलपर को लॉग की डिलीवरी से निपटने के लिए बना हुआ है। सबसे पहले, कोड में वर्तमान कॉल को बदलने के लिए न्यूनतम प्रयास के साथ आवेदन के बाहर लॉग भेजने वाले कॉल के साथ इसकी आवश्यकता थी। दूसरे, घटना के दृश्य को सही ढंग से स्थानीय बनाना आवश्यक था, अन्यथा वास्तविक कोड के साथ अपवाद को सहसंबंधित करना व्यावहारिक रूप से असंभव होगा। तीसरा, यह ध्यान दिया जाना चाहिए कि संशोधित परीक्षण यूनिट परीक्षण के दौरान काम कर सकते हैं, जहां Thread.isMainThread को पहले ही अनदेखा कर दिया जाना चाहिए। मैं कुछ प्रकार के परीक्षण के लिए RxTest ढांचे का उपयोग करता हूं (यहां मैं सलाह और आलोचना सुनने के लिए भी तैयार हूं)। मुख्य बिंदु यह रहा कि स्थानीय रूप से सभी अपवादों को पहले की तरह ट्रिगर किया जाना चाहिए, अर्थात। Loggin.assert() को उसी समय फायर करना चाहिए जब Swift.assert() फायर करेगा

फैब्रिक ( क्रैशलाईटिक्स ) घटनाओं को भेजने का एक शानदार तरीका प्रदान करता है। यह इस तरह दिखता है:

 Crashlytics.sharedInstance().recordCustomExceptionName("", reason: ""... 

यह क्रैशलाईटिक्स को कुछ ढांचे में पैक करने के लिए बना हुआ है, जिसे इसकी संपूर्णता में अनुप्रयोग में और परीक्षण के लक्ष्यों में क्रूसिएटेड (निर्भरता के बिना) में काट दिया जा सकता है।

मैंने कोकोपोड्स के माध्यम से " पैकेजिंग " करने का फैसला किया:

 Pod::Spec.new do |s| s.name = 'Logging' ... s.subspec 'Base' do |ss| ss.source_files = 'Source/Logging+Base.swift' ss.dependency 'Crashlytics' end s.subspec 'Test' do |ss| ss.source_files = 'Source/Logging+Test.swift' end end 

"मुकाबला लक्ष्य" के लिए कोड इस प्रकार है:

 import Crashlytics public enum Logging { public static func send(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { let file = __file.components(separatedBy: "/").last ?? __file let line = "\(__line)" let name = [line, file].joined(separator: "_") Crashlytics.sharedInstance().recordCustomExceptionName(name, reason: reason ?? "no reason", frameArray: []) } public static func assert(_ assertion: @escaping @autoclosure () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { if assertion() == false { self.assertionFailure(reason, __file: __file, __line: __line) } } public static func assert(_ assertion: @escaping () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { if assertion() == false { self.assertionFailure(reason, __file: __file, __line: __line) } } public static func assertionFailure(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { Swift.assertionFailure(reason ?? "") self.send(reason, __file: __file, __line: __line) } } 

"परीक्षण लक्ष्य" के लिए बिना Crashlytics निर्भरता:

 import Foundation public enum Logging { public static func send(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { // } public static func assert(_ assertion: @escaping @autoclosure () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { // } public static func assert(_ assertion: @escaping () -> Bool, reason: String? = nil, __file: String = #file, __line: Int = #line) { // } public static func assertionFailure(_ reason: String? = nil, __file: String = #file, __line: Int = #line) { // } } 

परिणाम:

अपवाद वास्तव में काम करना शुरू कर दिया। उनमें से अधिकांश ने प्राप्त आंकड़ों के लिए एक गलत प्रारूप की सूचना दी: Decodable कभी-कभी Decodable प्रकार के साथ डेटा प्राप्त होता है। कभी-कभी Thread.isMainThread लिए लॉग काम करते थे, जो अगले रिलीज़ में बहुत जल्दी तय हो गए थे। सबसे दिलचस्प त्रुटियों को चमत्कारिक रूप से NSException द्वारा पकड़ा गया था ।

आपका ध्यान के लिए धन्यवाद।

PS यदि आप भी अक्सर ऐसे लॉग को क्रैशलाईटिक्स भेजते हैं, तो सेवा आपके कार्यों को स्पैम के रूप में पहचान सकती है। और आपको निम्न संदेश दिखाई देगा:

अनुचित उपयोग के कारण, गैर-घातक रिपोर्टिंग को कई बिल्ड के लिए अक्षम कर दिया गया है। हमारे प्रलेखन में रिपोर्टिंग को फिर से सक्षम करने का तरीका जानें।

इसलिए, यह पहले से लॉग भेजने की आवृत्ति पर विचार करने के लायक है। अन्यथा, सभी बिल्ड लॉग को क्रैशलाईटिक्स द्वारा अनदेखा किए जाने का खतरा हो सकता है ।