2019年更新：
簡單說就是這樣：
原文如下：
最近看一些第三方的代碼有@try,一副看不懂的樣子,真心沒用過,于是查了些資料收集在這里,以后遇到就不會(huì)再蒙比了.其實(shí)這東西確實(shí)不怎么用,下文有解釋.
Objective-C 異常機(jī)制 :
-- 作用 : 開發(fā)者將引發(fā)異常的代碼放在 @try 代碼塊中, 程序出現(xiàn)異常 使用 @catch 代碼塊進(jìn)行捕捉;
-- 每個(gè)代碼塊作用 : @try 代碼塊存放可能出現(xiàn)異常的代碼, @catch 代碼塊 異常處理邏輯, @finally 代碼塊回收資源;
-- 語法示例 :
(http://www.2cto.com/kf/201510/444922.html#)
@try
{
// 業(yè)務(wù)邏輯
}
@catch (異常類型名1 ex)
{
//異常處理代碼
}
@catch (異常類型名2 ex)
{
//異常處理代碼
}
// 可以捕捉 N 個(gè) 異常 ...
@finally
{
//回收資源
}
(2) Objective-C 異常處理過程
**異常處理過程 **:
-- 生成異常對(duì)象 : @try 中出現(xiàn)異常, 系統(tǒng)會(huì)生成一個(gè)異常對(duì)象, 該對(duì)象提交到系統(tǒng)中 系統(tǒng)就會(huì)拋出異常;
-- **異常處理流程 **: 運(yùn)行環(huán)境接收到 異常對(duì)象時(shí), 如果存在能處理該異常對(duì)象的 @catch 代碼塊, 就將該異常對(duì)象交給 @catch 處理, 該過程就是捕獲異常, 如果沒有 @catch 代碼塊處理異常, 程序就會(huì)終止;
-- **@catch 代碼塊捕獲過程 **: 運(yùn)行環(huán)境接收到 異常對(duì)象 時(shí), 會(huì)依次判斷該異常對(duì)象類型是否是 @catch 代碼塊中異常或其子類實(shí)例, 如果匹配成功, 被匹配的 @catch 就會(huì)處理該異常, 都則就會(huì)跟下一個(gè) @catch 代碼塊對(duì)比;
-- @catch 處理異常 : 系統(tǒng)將異常對(duì)象傳遞給 @catch 形參, @catch 通過該形參獲取異常對(duì)象詳細(xì)信息;
其它注意點(diǎn) :
-- @try 與 @catch 對(duì)應(yīng)關(guān)系 : 一個(gè) @try 代碼塊 可以對(duì)應(yīng) 多個(gè) @catch 代碼塊;
-- {} 省略問題 : 異常捕獲的 @try @catch @finally 的花括號(hào)不可省略;
NSException 異常類 :
-- 簡介 : NSException 是 OC 中所有異常的父類;
-- 位置永遠(yuǎn)在最后 : @catch 代碼塊捕獲異常時(shí)查看 異常對(duì)象類型是否是 捕獲的異常類型 或者其子類, 一旦放在開頭, 后面的異常永遠(yuǎn)不可能捕獲;
(3) 異常信息訪問
異常信息訪問 :
-- name : 返回異常的詳細(xì)名稱;
-- reason : 返回異常引發(fā)的原因;
-- userInfo : 返回異常的用戶信息, 一個(gè) NSDictionary 對(duì)象;
2.ios****中很少用到****try ****和****catch**
簡單的來說，Apple雖然同時(shí)提供了錯(cuò)誤處理（NSError）和異常處理（exception）兩種機(jī)制，但是Apple更加提倡開發(fā)者使用NSError來處理程序運(yùn)行中可恢復(fù)的錯(cuò)誤。而異常被推薦用來處理不可恢復(fù)的錯(cuò)誤。
原因有幾個(gè)，在非gc情況下，exception容易造成內(nèi)存管理問題（文檔有描述即使是arc下，也不是安全的）；exception使用block造成額外的開銷，效率較低等等，另外這也的確是Cocoa開發(fā)者的習(xí)慣。（http://blog.csdn.net/x32sky/article/details/23753597）//怪不得我沒聽周圍IOS開發(fā)人員用這個(gè)
3.try,catch,finally****執(zhí)行流程**** ****（****http://blog.csdn.net/phoenix001/article/details/4293472****）
try{
//1:拋出異常的代碼
//2:代碼
}catch(){
//3:代碼
//4:拋出異常
}finally{
//5:代碼
}
//6:代碼
首先要明確的一點(diǎn)是：不管try是否拋出異常，finally語句塊都會(huì)執(zhí)行。
小心注意6！！
整個(gè)try,catch,finally執(zhí)行有以下幾種情況：
1：try語句塊沒有拋出異常。如果是這種情況，程序會(huì)執(zhí)行try,finally以及finally塊之后的代碼；
2：try語句塊拋出了異常并且catch有匹配的異常。當(dāng)遇到try里面拋出的異常后，try塊里面剩下的代碼就不執(zhí)行了，跳轉(zhuǎn)到catch塊里面。
這里又可以分為2種情況。第一種，拋出的異常被后面的catch捕獲，而catch又沒有拋出新的異常，那么執(zhí)行順序是1356 ;第二種，如果catch里面又拋出新的異常，順序是1345,然后將新的異常返回給方法調(diào)用者，6就不執(zhí)行了 ；
3:try語句塊拋出了異常，但是后面的catch沒有能匹配的異常。那么會(huì)執(zhí)行try和finally里面的語句也就是15,然后將該異常返回給方法調(diào)用者，不執(zhí)行6 。
總結(jié)：
如果異常不能被捕捉的話，finally{}后面的語句就不會(huì)執(zhí)行了，而finally{}一定被執(zhí)行
try catch還有一個(gè)靈活的巧用：
有時(shí)候我們加的全局?jǐn)帱c(diǎn)并不能跳到異常的代碼塊，并且沒有答應(yīng)任何異常信息，
我們根據(jù)異常的上下文 找到異常代碼塊但是不知道到底是報(bào)的什么異常，
那么可以對(duì)那個(gè)異常代碼塊包上一個(gè)try catch ，
然后在catch中打印exception的內(nèi)容，這樣就能夠知道到底是出現(xiàn)了什么異常。
每當(dāng)出現(xiàn)bug或者crash的時(shí)候，我們總是習(xí)慣性的加入了NSLog或則單步調(diào)試。
