十年網(wǎng)站開發(fā)經(jīng)驗(yàn) + 多家企業(yè)客戶 + 靠譜的建站團(tuán)隊(duì)
量身定制 + 運(yùn)營(yíng)維護(hù)+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
go語言中的if語句和其他語言中的類似,都是根據(jù)給定的條件表達(dá)式運(yùn)算結(jié)果來,判斷執(zhí)行流程。
創(chuàng)新互聯(lián)是一家專業(yè)提供大同企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、成都做網(wǎng)站、H5技術(shù)、小程序制作等業(yè)務(wù)。10年已為大同眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。
注意:在go語言中 布爾表達(dá)式不用使用括號(hào)。
根據(jù)布爾值flag判斷
程序運(yùn)行結(jié)果
初始變量可以聲明在布爾表達(dá)式里面,注意它的作用域
程序運(yùn)行結(jié)果
注意:不能使用0或非0表示真假
go語言if語句使用提示:
go語言中的if else語句可以根據(jù)給定條件二選一。
比較兩個(gè)數(shù)的大小
運(yùn)行結(jié)果
判斷一個(gè)數(shù)是奇數(shù)還是偶數(shù)
運(yùn)行結(jié)果
判斷一個(gè)人是否成年
運(yùn)行結(jié)果
特殊寫法,在if前面添加執(zhí)行語句
運(yùn)行結(jié)果
go語言if語句使用提示:
go語言if語句可以進(jìn)行多重嵌套使用,進(jìn)行多重判斷。
根據(jù)分?jǐn)?shù)判斷等級(jí)
運(yùn)行結(jié)果
同樣也可以寫成這樣
運(yùn)行結(jié)果
輸入星期幾的第一個(gè)字母來判斷一下是星期幾,如果第一個(gè)字母一樣,則繼續(xù)判斷第二個(gè)字母
運(yùn)行結(jié)果
go語言if語句可以嵌套多級(jí)進(jìn)行判斷。
判斷三個(gè)數(shù)的大小
運(yùn)行結(jié)果
判斷男生還是女生,還有是否成年
運(yùn)行結(jié)果
CPU 執(zhí)行除法指令(如:DIV? CX、DIV? BL)時(shí),是有可能溢出的。
如果被除數(shù)較大,或除數(shù)較小,都可能使“商”超出預(yù)定位數(shù),此時(shí),就會(huì)溢出。
特別是當(dāng)除數(shù)為零時(shí),必然會(huì)出現(xiàn):Divide? overflow。
直接使用 DIV 指令,有一定的風(fēng)險(xiǎn),一不小心就溢出了。
特別是數(shù)字不明確的時(shí)候。
因此,在執(zhí)行 DIV 指令之前,應(yīng)該加以判斷,以免發(fā)生溢出。
一般來說,當(dāng)被除數(shù)的高位,小于除數(shù)時(shí),就不會(huì)發(fā)生“溢出”。
如果高位為零,比如 DX = 0、AH = 0,這就肯定不會(huì)溢出。
-----------------------
較好的方法是:編寫一個(gè)“不會(huì)溢出”的除法程序。
方法思路如下:
左圖是 CPU 執(zhí)行 16 位數(shù)除以 8 位數(shù)時(shí)的操作。
在右圖中,
被除數(shù):1A 2B 3C 4DH,有 32 位數(shù)。
除數(shù)是:BL,僅有 8 位數(shù)。
商,是:32 位數(shù)。
按照?qǐng)D中的步驟,需要執(zhí)行四次 DIV? BL。
只要 BL 不為零,就絕對(duì)不會(huì)發(fā)生溢出。
按此思路,被除數(shù)的字節(jié)數(shù),可以繼續(xù)增加,僅受制于內(nèi)存的大小。
這就是說:被除數(shù),可以認(rèn)為是無限的。
在本節(jié)中,您將添加通用函數(shù)調(diào)用的修改版本,進(jìn)行小的更改以簡(jiǎn)化調(diào)用代碼。您將刪除在這種情況下不需要的類型參數(shù)。
當(dāng) Go 編譯器可以推斷您要使用的類型時(shí),您可以在調(diào)用代碼中省略類型參數(shù)。編譯器從函數(shù)參數(shù)的類型推斷類型參數(shù)。
請(qǐng)注意,這并不總是可能的。例如,如果您需要調(diào)用沒有參數(shù)的泛型函數(shù),則需要在函數(shù)調(diào)用中包含類型參數(shù)。
在 main.go 中,在您已有的代碼下方,粘貼以下代碼。
在此代碼中:
(1)調(diào)用泛型函數(shù),省略類型參數(shù)。
從包含 main.go 的目錄中的命令行,運(yùn)行代碼。
接下來,您將通過將整數(shù)和浮點(diǎn)數(shù)的并集捕獲到您可以重用的類型約束(例如從其他代碼中)來進(jìn)一步簡(jiǎn)化函數(shù)。
正如您將在本節(jié)中看到的,約束接口也可以引用特定類型。
1、編寫代碼
在此代碼中:
b.在您已有的函數(shù)下方,粘貼以下通用 SumNumbers函數(shù)。
在此代碼中:
c.在 main.go 中,在您已有的代碼下方,粘貼以下代碼。
在此代碼中:
(1)調(diào)用SumNumbers打印每個(gè)map的總和。
與上一節(jié)一樣,在調(diào)用泛型函數(shù)時(shí)省略了類型參數(shù)(方括號(hào)中的類型名稱)。Go 編譯器可以從其他參數(shù)推斷類型參數(shù)。
從包含 main.go 的目錄中的命令行,運(yùn)行代碼。
做得很好!您剛剛學(xué)習(xí)了 Go 中的泛型。
這個(gè)問題說來話長(zhǎng),我先表達(dá)一下我的觀點(diǎn),Go語言從語法層面提供區(qū)分錯(cuò)誤和異常的機(jī)制是很好的做法,比自己用單個(gè)返回值做值判斷要方便很多。
上面看到很多知乎大牛把異常和錯(cuò)誤混在一起說,有認(rèn)為Go沒有異常機(jī)制的,有認(rèn)為Go純粹只有異常機(jī)制的,我覺得這些觀點(diǎn)都太片面了。
具體對(duì)于錯(cuò)誤和異常的討論,我轉(zhuǎn)發(fā)一下前陣子寫的一篇日志拋磚引玉吧。
============================
最近連續(xù)遇到朋友問我項(xiàng)目里錯(cuò)誤和異常管理的事情,之前也多次跟團(tuán)隊(duì)強(qiáng)調(diào)過錯(cuò)誤和異常管理的一些概念,所以趁今天有動(dòng)力就趕緊寫一篇Go語言項(xiàng)目錯(cuò)誤和異常管理的經(jīng)驗(yàn)分享。
首先我們要理清:什么是錯(cuò)誤、什么是異常、為什么需要管理。然后才是怎樣管理。
錯(cuò)誤和異常從語言機(jī)制上面講,就是error和panic的區(qū)別,放到別的語言也一樣,別的語言沒有error類型,但是有錯(cuò)誤碼之類的,沒有panic,但是有throw之類的。
在語言層面它們是兩種概念,導(dǎo)致的是兩種不同的結(jié)果。如果程序遇到錯(cuò)誤不處理,那么可能進(jìn)一步的產(chǎn)生業(yè)務(wù)上的錯(cuò)誤,比如給用戶多扣錢了,或者進(jìn)一步產(chǎn)生了異常;如果程序遇到異常不處理,那么結(jié)果就是進(jìn)程異常退出。
在項(xiàng)目里面是不是應(yīng)該處理所有的錯(cuò)誤情況和捕捉所有的異常呢?我只能說,你可以這么做,但是估計(jì)效果不會(huì)太好。我的理由是:
如果所有東西都處理和記錄,那么重要信息可能被淹沒在信息的海洋里。
不應(yīng)該處理的錯(cuò)誤被處理了,很容易導(dǎo)出BUG暴露不出來,直到出現(xiàn)更嚴(yán)重錯(cuò)誤的時(shí)候才暴露出問題,到時(shí)候排查就很困難了,因?yàn)橐呀?jīng)不是錯(cuò)誤的第一現(xiàn)場(chǎng)。
所以錯(cuò)誤和異常最好能按一定的規(guī)則進(jìn)行分類和管理,在第一時(shí)間能暴露錯(cuò)誤和還原現(xiàn)場(chǎng)。
對(duì)于錯(cuò)誤處理,Erlang有一個(gè)很好的概念叫速錯(cuò),就是有錯(cuò)誤第一時(shí)間暴露它。我們的項(xiàng)目從Erlang到Go一直是沿用這一設(shè)計(jì)原則。但是應(yīng)用這個(gè)原則的前提是先得區(qū)分錯(cuò)誤和異常這兩個(gè)概念。
錯(cuò)誤和異常上面已經(jīng)提到了,從語言機(jī)制層面比較容易區(qū)分它們,但是語言取決于人為,什么情況下用錯(cuò)誤表達(dá),什么情況下用異常表達(dá),就得有一套規(guī)則,否則很容易出現(xiàn)全部靠異常來做錯(cuò)誤處理的情況,似乎Java項(xiàng)目特別容易出現(xiàn)這樣的設(shè)計(jì)。
這里我先假想有這樣一個(gè)業(yè)務(wù):游戲玩家通過購買按鈕,用銅錢購買寶石。
在實(shí)現(xiàn)這個(gè)業(yè)務(wù)的時(shí)候,程序邏輯會(huì)進(jìn)一步分化成客戶端邏輯和服務(wù)端邏輯,客戶端邏輯又進(jìn)一步因?yàn)樵O(shè)計(jì)方式的不同分化成兩種結(jié)構(gòu):胖客戶端結(jié)構(gòu)、瘦客戶端結(jié)構(gòu)。
胖客戶端結(jié)構(gòu),有更多的本地?cái)?shù)據(jù)和懂得更多的業(yè)務(wù)邏輯,所以在胖客戶端結(jié)構(gòu)的應(yīng)用中,以上的業(yè)務(wù)會(huì)實(shí)現(xiàn)成這樣:客戶端檢查緩存中的銅錢數(shù)量,銅錢數(shù)量足夠的時(shí)候購買按鈕為可用的亮起狀態(tài),用戶點(diǎn)擊購買按鈕后客戶端發(fā)送購買請(qǐng)求到服務(wù)端;服務(wù)端收到請(qǐng)求后校驗(yàn)用戶的銅錢數(shù)量,如果銅錢數(shù)量不足就拋出異常,終止請(qǐng)求過程并斷開客戶端的連接,如果銅錢數(shù)量足夠就進(jìn)一步完成寶石購買過程,這里不繼續(xù)描述正常過程。
因?yàn)檎5目蛻舳耸怯幸徊綌?shù)據(jù)校驗(yàn)的過程的,所以當(dāng)服務(wù)端收到不合理的請(qǐng)求(銅錢不足以購買寶石)時(shí),拋出異常比返回錯(cuò)誤更為合理,因?yàn)檫@個(gè)請(qǐng)求只可能來自兩種客戶端:外掛或者有BUG的客戶端。如果不通過拋出異常來終止業(yè)務(wù)過程和斷開客戶端連接,那么程序的錯(cuò)誤就很難被第一時(shí)間發(fā)現(xiàn),攻擊行為也很難被發(fā)現(xiàn)。
我們?cè)倩仡^看瘦客戶端結(jié)構(gòu)的設(shè)計(jì),瘦客戶端不會(huì)存有太多狀態(tài)數(shù)據(jù)和用戶數(shù)據(jù)也不清楚業(yè)務(wù)邏輯,所以客戶端的設(shè)計(jì)會(huì)是這樣:用戶點(diǎn)擊購買按鈕,客戶端發(fā)送購買請(qǐng)求;服務(wù)端收到請(qǐng)求后檢查銅錢數(shù)量,數(shù)量不足就返回?cái)?shù)量不足的錯(cuò)誤碼,數(shù)量足夠就繼續(xù)完成業(yè)務(wù)并返回成功信息;客戶端收到服務(wù)端的處理結(jié)果后,在界面上做出反映。
在這種結(jié)構(gòu)下,銅錢不足就變成了業(yè)務(wù)邏輯范圍內(nèi)的一種失敗情況,但不能提升為異常,否則銅錢不足的用戶一點(diǎn)購買按鈕都會(huì)出錯(cuò)掉線。
所以,異常和錯(cuò)誤在不同程序結(jié)構(gòu)下是互相轉(zhuǎn)換的,我們沒辦法一句話的給所有類型所有結(jié)構(gòu)的程序一個(gè)統(tǒng)一的異常和錯(cuò)誤分類規(guī)則。
但是,異常和錯(cuò)誤的分類是有跡可循的。比如上面提到的痩客戶端結(jié)構(gòu),銅錢不足是業(yè)務(wù)邏輯范圍內(nèi)的一種失敗情況,它屬于業(yè)務(wù)錯(cuò)誤,再比如程序邏輯上嘗試請(qǐng)求某個(gè)URL,最多三次,重試三次的過程中請(qǐng)求失敗是錯(cuò)誤,重試到第三次,失敗就被提升為異常了。
所以我們可以這樣來歸類異常和錯(cuò)誤:不會(huì)終止程序邏輯運(yùn)行的歸類為錯(cuò)誤,會(huì)終止程序邏輯運(yùn)行的歸類為異常。
因?yàn)殄e(cuò)誤不會(huì)終止邏輯運(yùn)行,所以錯(cuò)誤是邏輯的一部分,比如上面提到的瘦客戶端結(jié)構(gòu),銅錢不足的錯(cuò)誤就是業(yè)務(wù)邏輯處理過程中需要考慮和處理的一個(gè)邏輯分支。而異常就是那些不應(yīng)該出現(xiàn)在業(yè)務(wù)邏輯中的東西,比如上面提到的胖客戶端結(jié)構(gòu),銅錢不足已經(jīng)不是業(yè)務(wù)邏輯需要考慮的一部分了,所以它應(yīng)該是一個(gè)異常。
錯(cuò)誤和異常的分類需要通過一定的思維訓(xùn)練來強(qiáng)化分類能力,就類似于面向?qū)ο蟮脑O(shè)計(jì)方式一樣的,技術(shù)實(shí)現(xiàn)就擺在那邊,但是要用好需要不斷的思維訓(xùn)練不斷的歸類和總結(jié),以上提到的歸類方式希望可以作為一個(gè)參考,期待大家能發(fā)現(xiàn)更多更有效的歸類方式。
接下來我們講一下速錯(cuò)和Go語言里面怎么做到速錯(cuò)。
速錯(cuò)我最早接觸是在做的時(shí)候就體驗(yàn)到的,當(dāng)然跟Erlang的速錯(cuò)不完全一致,那時(shí)候也沒有那么高大上的一個(gè)名字,但是對(duì)待異常的理念是一樣的。
在.NET項(xiàng)目開發(fā)的時(shí)候,有經(jīng)驗(yàn)的程序員都應(yīng)該知道,不能隨便re-throw,就是catch錯(cuò)誤再拋出,原因是異常的第一現(xiàn)場(chǎng)會(huì)被破壞,堆棧跟蹤信息會(huì)丟失,因?yàn)橥獠孔詈竽玫疆惓5亩褩8櫺畔ⅲ亲詈竽谴蝨hrow的異常的堆棧跟蹤信息;其次,不能隨便try catch,隨便catch很容易導(dǎo)出異常暴露不出來,升級(jí)為更嚴(yán)重的業(yè)務(wù)漏洞。
到了Erlang時(shí)期,大家學(xué)到了速錯(cuò)概念,簡(jiǎn)單來講就是:讓它掛。只有掛了你才會(huì)第一時(shí)間知道錯(cuò)誤,但是Erlang的掛,只是Erlang進(jìn)程的異常退出,不會(huì)導(dǎo)致整個(gè)Erlang節(jié)點(diǎn)退出,所以它掛的影響層面比較低。
在Go語言項(xiàng)目中,雖然有類似Erlang進(jìn)程的Goroutine,但是Goroutine如果panic了,并且沒有recover,那么整個(gè)Go進(jìn)程就會(huì)異常退出。所以我們?cè)贕o語言項(xiàng)目中要應(yīng)用速錯(cuò)的設(shè)計(jì)理念,就要對(duì)Goroutine做一定的管理。
在我們的游戲服務(wù)端項(xiàng)目中,我把Goroutine按掛掉后的結(jié)果分為兩類:1、掛掉后不影響其他業(yè)務(wù)或功能的;2、掛掉后業(yè)務(wù)就無法正常進(jìn)行的。
第一類Goroutine典型的有:處理各個(gè)玩家請(qǐng)求的Goroutine,因?yàn)槊總€(gè)玩家連接各自有一個(gè)Goroutine,所以掛掉了只會(huì)影響單個(gè)玩家,不會(huì)影響整體業(yè)務(wù)進(jìn)行。
第二類Goroutine典型的有:數(shù)據(jù)庫同步用的Goroutine,如果它掛了,數(shù)據(jù)就無法同步到數(shù)據(jù)庫,游戲如果繼續(xù)運(yùn)行下去只會(huì)導(dǎo)致數(shù)據(jù)回檔,還不如讓整個(gè)游戲都異常退出。
這樣一分類,就可以比較清楚哪些Goroutine該做recover處理,哪些不該做recover處理了。
那么在做recover處理時(shí),要怎樣才能盡量保留第一現(xiàn)場(chǎng)來幫組開發(fā)者排查問題原因呢?我們項(xiàng)目中通常是會(huì)在最外層的recover中把錯(cuò)誤和堆棧跟蹤信息記進(jìn)日志,同時(shí)把關(guān)鍵的業(yè)務(wù)信息,比如:用戶ID、來源IP、請(qǐng)求數(shù)據(jù)等也一起記錄進(jìn)去。
為此,我們還特地設(shè)計(jì)了一個(gè)庫,用來格式化輸出堆棧跟蹤信息和對(duì)象信息,項(xiàng)目地址:funny/debug · GitHub
通篇寫下來發(fā)現(xiàn)比我預(yù)期的長(zhǎng)很多,所以這里我做一下歸納總結(jié),幫組大家理解這篇文章所要表達(dá)的:
錯(cuò)誤和異常需要分類和管理,不能一概而論
錯(cuò)誤和異常的分類可以以是否終止業(yè)務(wù)過程作為標(biāo)準(zhǔn)
錯(cuò)誤是業(yè)務(wù)過程的一部分,異常不是
不要隨便捕獲異常,更不要隨便捕獲再重新拋出異常
Go語言項(xiàng)目需要把Goroutine分為兩類,區(qū)別處理異常
在捕獲到異常時(shí),需要盡可能的保留第一現(xiàn)場(chǎng)的關(guān)鍵數(shù)據(jù)
以上僅為一家之言,拋磚引玉,希望對(duì)大家有所幫助。