असफल होने पर एक NSAssert अपवाद फेंक देगा। तो NSAssert लिखने के लिए और आपके कोड में आपके द्वारा की गई किसी भी मान्यताओं की जांच करने के लिए छोटा और आसान तरीका है। यह (मेरी राय में) अपवादों का विकल्प नहीं है, सिर्फ एक शॉर्टकट है। यदि एक जोरदार विफल रहता है तो आपके कोड में कुछ गलत हो गया है और कार्यक्रम जारी नहीं होना चाहिए।
ध्यान देने वाली बात यह है कि NSAssert एक रिलीज बिल्ड में आपके कोड में संकलित नहीं किया जाएगा, इसलिए यह आमतौर पर विकास के लिए स्वच्छता की जाँच के लिए उपयोग किया जाता है। मैं वास्तव में एक कस्टम मुखर मैक्रो का उपयोग करता हूं जो हमेशा सक्रिय रहता है।
जिस समय आप @throwअपने स्वयं के NSException होंगे , जब आप निश्चित रूप से इसे रिलीज़ बिल्ड में चाहते हैं, और सार्वजनिक पुस्तकालयों / इंटरफ़ेस जैसी चीजों में जब कुछ तर्क अमान्य हैं या आपको गलत तरीके से बुलाया गया है। ध्यान दें कि यह वास्तव में @catchएक अपवाद के लिए मानक अभ्यास नहीं है और अपना एप्लिकेशन चलाना जारी रखें। यदि आप एप्पल के कुछ मानक पुस्तकालयों (उदाहरण के लिए कोर डेटा) के साथ यह कोशिश करते हैं तो बुरी चीजें हो सकती हैं। एक मुखर के समान, अगर एक अपवाद को फेंक दिया जाता है, तो एप्लिकेशन को आमतौर पर काफी जल्दी समाप्त करना चाहिए क्योंकि इसका मतलब है कि कहीं न कहीं एक प्रोग्रामिंग त्रुटि है।
NSErrors को आपके पुस्तकालयों / इंटरफेस में उन त्रुटियों के लिए उपयोग किया जाना चाहिए जो प्रोग्रामिंग त्रुटियां नहीं हैं, और जिनसे पुनर्प्राप्त किया जा सकता है। आप कॉल करने वाले को सूचना / त्रुटि कोड प्रदान कर सकते हैं और वे त्रुटि को सफाई से संभाल सकते हैं, यदि उपयुक्त हो तो उपयोगकर्ता को सचेत कर सकते हैं और निष्पादन जारी रख सकते हैं। यह आमतौर पर फाइल-नहीं-पाया त्रुटि या कुछ अन्य गैर-घातक त्रुटि जैसी चीजों के लिए होगा।