丨panic函數(shù)recover以及defer語句上

我們舉個(gè)具體的例子來看看比如說，一個(gè)Go程序里有一個(gè)切片，它的長度是5，也就是說該切片中的元素值的索引分別為0、1、2、3、4，但是，我在程序里卻想通過索引5其中的元素值，顯而易見，這樣的是不正確的。Go程序，確切地說是程序內(nèi)嵌的Go語言運(yùn)行時(shí)系統(tǒng)，會(huì)在執(zhí)行到這行代碼的時(shí)候拋出一個(gè)“indexoutofrange”的panic，用以提示你索引越界了。當(dāng)然了，這不僅僅是個(gè)提示。當(dāng)panic被拋出之后，如果我們沒有在程序里添加任何保護(hù)措施的話，程序（或者說代表它的那個(gè)進(jìn)程）就會(huì)在打印出panic的詳細(xì)情況（以下簡稱panic詳情）之后，終止運(yùn)行?，F(xiàn)在，就讓我們來看一下這樣的panic詳情中都有什么代1panic:runtimeerror:indexoutof2goroutine1 exitstatus這份詳情的第一行是“pa:rnimeerror:indexoutfrane”。其中的“runimeerror”的含義是，這是一個(gè)runtie代碼包中拋出的aic。在這個(gè)panic中，包含了一個(gè)runime.Eror接口類型的值。runtimeError接口內(nèi)嵌了eror接口，并做了一點(diǎn)點(diǎn)擴(kuò)展，runtme包中有不少它的實(shí)現(xiàn)類型。實(shí)際上，此詳情中的“panic：”右邊的內(nèi)容，正是這個(gè)panicruntime.Error類此外，panic詳情中，一般還會(huì)包含與它的原因有關(guān)的goroutine的代碼執(zhí)行信息。正如前述詳情中的“goroutine1[running]”，它表示有一個(gè)ID為1的goroutine在此panic被的時(shí)候正在運(yùn)行。注意，這里的ID其實(shí)并不重要，因?yàn)樗皇荊o語言運(yùn)行時(shí)系統(tǒng)內(nèi)部給予的一goroutine編號，我們在程序中是無法獲取和更改的我們再看下一行，“main.main()”表明了這個(gè)goroutine包裝的go函數(shù)就是命令源碼文件中的那個(gè)main函數(shù)，也就是說這里的goroutine是主goroutine。再下面的一行，指出的就是這個(gè)goroutine中的哪一行代碼在此panic被時(shí)正在執(zhí)行。這包含了此行代碼在其所屬的源碼文件中的行數(shù)，以及這個(gè)源碼文件的絕對路徑。這一行最后的+0x3d代表的是：此行代碼相對于其所屬函數(shù)的程序計(jì)數(shù)偏移量。不過，一般情況下它的用處并不大。最后，“exitstatus2”表明我的這個(gè)程序是以退出狀態(tài)碼2結(jié)束運(yùn)行的。在大多數(shù)操作系統(tǒng)中，只要退出狀態(tài)碼不是0，都意味著程序運(yùn)行的結(jié)束。在Go語言中，因panic綜上所述，我們從上邊的這個(gè)panic詳情可以看 作為此panic的根源的代碼處demo47.go文件中的第5行 那么，我的第一個(gè)問題也隨之而來了。我今天的問題是：從panic被到程序終止運(yùn)行這道題的典型回答是這樣的我們先說一個(gè)大致的過程：某個(gè)函數(shù)中的某行代碼有意或無意地了一個(gè)panic。這時(shí)，初始的panic詳情會(huì)被建立起來，并且該程序的控制權(quán)會(huì)立即從此行代碼轉(zhuǎn)移至調(diào)用其所這也意味著，此行代碼所屬函數(shù)的執(zhí)行隨即終止。緊接著，控制權(quán)并不會(huì)在此有片刻的停留，它又會(huì)立即轉(zhuǎn)移至再上一級的調(diào)用代碼處?？刂茩?quán)如此一級一級地沿著調(diào)用棧的反方向至頂端，也就是我們編寫的最外層函數(shù)那里。這里的最外層函數(shù)指的是go函數(shù)，對于主goroutine來說就是main函數(shù)。但是控制權(quán)也不會(huì)停留在那里，而是被Go語言運(yùn)行時(shí)系統(tǒng)收回。隨后，程序并終止運(yùn)行，承載程序這次運(yùn)行的進(jìn)程也會(huì)隨之并。與此同時(shí)，在這個(gè)控制權(quán)的過程中，panic詳情會(huì)被逐漸地積累和完善，并會(huì)在程序終止之前被打印panic可能是我們在無意間（或者說一不）的，如前文所述的索引越界。這類panic真正的、在我們意料之外的程序異常。不過，除此之外，我們還是可以有意地Go語言的內(nèi)建函數(shù)panic是專門用于panic的。panic函數(shù)使程序開發(fā)者可以在程序注意，這與從函數(shù)返回錯(cuò)誤值的意義是完全不同的。當(dāng)我們的函數(shù)返回一個(gè)非nil的錯(cuò)誤值時(shí)，函數(shù)的調(diào)用方有權(quán)選擇不處理，并且不處理的往往是不致命的。這里的“不致命”的意思是，不至于使程序無法提供任何功能（也可以說僵死）或者直接崩潰并終止運(yùn)行（也就是真死）。但是，當(dāng)一個(gè)panic發(fā)生時(shí)，如果我們不施加任何保護(hù)措施，那么導(dǎo)致的直接就是程為了更清楚地展示答案中描述的過程，我編寫了demo48.go件。你可以先查看一下其我在這里再提示一點(diǎn)。panic詳情會(huì)在控制權(quán)的過程中，被逐漸地積累和完善，并且，因此，在針對某個(gè)goroutine代碼執(zhí)行信息中，調(diào)用棧底端的信息會(huì)先出現(xiàn)，然后是上比如，main函數(shù)調(diào)用了caler1函數(shù)，而caler1函數(shù)又調(diào)用了caller2函數(shù)，那么caler2函數(shù)中代碼的執(zhí)行信息會(huì)先出現(xiàn)，然后是callr1函數(shù)中代碼的執(zhí)行信息，最后才是main函數(shù)的信息。代goroutine1 exitstatus（從panic到程序好了，到這里，我相信你已經(jīng)對panic被后的程序終止過程有一定的了解了。深入地了解此過程，以及正確地解讀panic詳情應(yīng)該是我們的必備技能，這在調(diào)試Go程序或者為Go程序排查錯(cuò)誤的時(shí)候非常重要。最近的兩篇文章，我們是圍繞著panic函數(shù)、recover函數(shù)以及defer語句進(jìn)行的。今天我主要講了panic函數(shù)。這個(gè)函數(shù)是專門被用來panic的。panic也可以被稱為運(yùn)行Go語言的運(yùn)行時(shí)系統(tǒng)可能會(huì)在程序出現(xiàn)嚴(yán)重錯(cuò)誤時(shí)自動(dòng)地拋出panic，我們在需要時(shí)也可以通過調(diào)用panic函數(shù)panic。但不論怎樣，如果不加以處理，panic就會(huì)導(dǎo)致程序崩一個(gè)函數(shù)怎樣才能把panic化為error類型值，并將其作為函數(shù)的結(jié)果值返回給調(diào)用戳此查看Go語言專欄文章配套詳細(xì)代 歸科技所有 不得售賣。頁面已增加防盜追蹤，將依法其上一篇20|錯(cuò)誤處理（下下一篇22|panic函數(shù)、recover函數(shù)以及defer語句（下言精選留言言 4先使用go中的類似trycatch這樣的語句，將異常捕獲的異常轉(zhuǎn)為相應(yīng)的錯(cuò)誤error唐 郝大，你好，我在golang8中通過recover處理panic時(shí)發(fā)現(xiàn)，必須在panic的當(dāng)前協(xié)來區(qū)分是不是在當(dāng)前協(xié)程的panic的嗎？另外，這樣的話，我們應(yīng)用程序中每一個(gè)通過go新起的協(xié)程都應(yīng)該在開始的地方recover，否則即使父協(xié)程有recover也不能程序…作者回復(fù):只要在調(diào)用棧路徑上就都可以處理，如果你用了de