स्विफ्ट: क्या एनएसईआरआर अब विरासत के रूप में माना जाना चाहिए?

Question

दस्तावेज़ और लोकप्रिय ब्लॉग सुझाव देते हैं कि स्विफ्ट एरर हैंडलिंग डू-कैच के साथ किया जाए और एक त्रुटि टाइप एनम या एनएसईआरआरआर उदाहरण को संभालने के लिए किया जाए।

क्या एररटाइप enum और एनएसईआरआरआर एक कोशिश पकड़ ब्लॉक में परस्पर अनन्य उदाहरण हैं? यदि नहीं, तो आप दोनों फ़ंक्शन को कैसे कार्यान्वित करते हैं?

मैंने एनएसईआरआर उदाहरण को इस तरह के एक enum से जोड़ा है, जो काम करता प्रतीत होता है, लेकिन क्या यह विस्तृत त्रुटि जानकारी लौटने का एक वास्तविक तरीका है?

enum Length : ErrorType { 
    case NotLongEnough(NSError) 
    case TooLong(NSError) 
} 

func myFunction() throws { 
    throw Length.NotLongEnough(NSError(domain: "domain", code: 0, userInfo: [NSLocalizedFailureReasonErrorKey: "Not long enough mate"])) 
} 

do { 
    try myFunction() 
} catch Length.NotLongEnough(let error) { 
    print("\(error)") 
} 

यह उदाहरण दिखाता है कि त्रुटि प्रकार को एनएसईआरआरआर में कैसे डाला जा सकता है।

do { 
    let str = try NSString(contentsOfFile: "Foo.bar", 
          encoding: NSUTF8StringEncoding) 
} 
catch let error as NSError { 
    print(error.localizedDescription) 
} 

मैं एक त्रुटि enum के लिए NSString तो हम यह मान लेना चाहिए कि यह एक NSError उदाहरण हो जाएगा ERRORTYPE के अनुरूप है कि नहीं मिल सकता है? अनुमोदित हम सुनिश्चित करने के लिए कोड चला सकते हैं, लेकिन निश्चित रूप से दस्तावेज़ हमें बताना चाहिए। (मुझे सराहना है कि मैंने दस्तावेज़ों को गलत तरीके से पढ़ा होगा)

Answer 1

NSError वर्ग ErrorType इंटरफ़ेस को गोद ले और किसी भी ErrorType -conformant वर्ग NSError लिए casted जा सकता है। इन विशेषताओं को here in the docs वर्णित किया गया है।

आप सुरक्षित रूप से ErrorType पर चिपके रह सकते हैं, खासकर यदि आप केवल स्विफ्ट के साथ इंटरऑपरेट करने की योजना बना रहे हैं।

enum CommonError: ErrorType { 
    case InternalInconsistency(String) 
} 

func boom() throws { 
    throw CommonError.InternalInconsistency("Boom!") 
} 

do { 
    try boom() 
} catch { 
    print(error) // InternalInconsistency("Boom!") 
    print(error as NSError) // Error Domain=CommonError Code=0 "(null)" 
} 

do { 
    try boom() 
} catch let CommonError.InternalInconsistency(msg) { 
    print("Error: \(msg)") // Error: Boom! 
} 

Answer 2

कोई भी त्रुटि टाइप सफलतापूर्वक NSError पर डाला जा सकता है, जिसका अर्थ है कि यदि आप प्राथमिकता के रूप में त्रुटि टाइप को संभालना चाहते हैं, या विशिष्ट त्रुटि टाइप कॉन्फॉर्मेंट स्विफ्ट प्रकार, तो आपके पास होना चाहिए एक मामले से पहले मामले जहां आपने NSError पर डाला था (जो, फिर से, सभी ErrorType चींटी प्रकारों के अनुरूप होगा)।

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

समस्याएं ज्यादातर नहीं कुछ महत्वपूर्ण प्रासंगिक जानकारी NSError में शामिल है कि अतिरिक्त bespoke काम हर समय देता कमी बताने के लिए ErrorType साथ त्रुटियों की किस तरह, एक विधि द्वारा फेंक दिया जाता है संयुक्त सक्षम किया जा रहा से उत्पन्न होती हैं आप उपयोगकर्ता को किसी भी तरह यूआई में ErrorType एस प्रस्तुत करना चाहते हैं। एनएसईआरआर के विपरीत, एररटाइप के पास "कारण" या "पुनर्प्राप्ति सुझाव" या वास्तव में "विवरण" जैसे यूआई इच्छित जानकारी को पास करने का कोई तरीका नहीं है। ऐसा लगता है कि स्विफ्ट 3 के लिए अभी भी इसे संबोधित नहीं किया जाएगा (स्विफ्ट विकास मेलिंग सूची पर इस पर हाल ही में कुछ चर्चा हुई है)।

के बारे में मैं वास्तव में यकीन है कि मैं सही ढंग से इस वाक्यांश समझा या क्या यह सही ढंग से समग्र शब्दों में है नहीं कर रहा हूँ "मैं एक त्रुटि enum NSString के लिए ERRORTYPE के अनुरूप है कि नहीं मिल सकता है", लेकिन शायद निम्नलिखित प्रासंगिक है:

मैं व्यक्तिगत रूप से ErrorType कार्यान्वयन CustomStringConvertible बनाने और description संपत्ति का उपयोग करने के सम्मेलन का पालन करता हूं ताकि त्रुटि के मानव (यूआई इरादे) पठनीय वर्णन का वर्णन किया जा सके। यह किसी भी तरह से सही नहीं है और खासकर ओएसएक्स पर जहां NSResponder अच्छी तरह से आपको presentError विधि देता है जो आपको & रिकवरी सुझाव जानकारी भरने पर बहुत अच्छा और स्पष्ट त्रुटि संवाद देता है।