iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 6
1
自我挑戰組

Let's Eat GO ! 實務開發雜談by Golang系列 第 6

Day6 .[重災經驗篇] … 的傳入參數方式,自由度很大,但還是要小心

說明

利用...的寫法,可以在function的設計提供彈性,傳入幾個參數交由使用者做決定,傳入的內容彙整成同樣型態的slice。

slice,亦即裡面的元素是可以0個,換句話說沒有傳入任何一個,也是可行,不過萬萬沒想到就是因為可能傳入了0個,造成後續的錯誤。

程式碼示意

go playground

事發經過

本身...的部分傳入0個參數是沒有問題的,程式本身沒錯,錯在於後續的程式,若業務邏輯預期一定會有一個以上的資料,那麽是哪邊要負責?

如下面的function,是goredis的SUnion函式,既然你要使用union,那麼就傳入要做union的set key

func (c cmdable) SUnion(keys ...string) *StringSliceCmd {
	args := make([]interface{}, 1+len(keys))
	args[0] = "sunion"
	for i, key := range keys {
		args[1+i] = key
	}
	cmd := NewStringSliceCmd(args...)
	c(cmd)
	return cmd
}

但是實際上,要把什麼key丟下去做union,我也不確定,所以準備了一個string slice,程式執行了某些操作得知哪些key要做union,先收集到slice在傳入這個SUnion。

絕大部分時候,都是有資料要請這個method幫忙做union的處理,99%以上的時候。

所以當那不到1%的機會觸發陷阱後,看到報錯時我一臉矇逼。

心裏OS:既然傳入的key數量是0,自動不要做就好啦,怎麼是炸掉勒。

又想想,也許當初套件的設計者就覺得,要使用Union,就不會有人沒傳任何東西進來吧。

於是,就理所當然的導致程式爆炸了。

事後檢討

這也許不是什麼很重大的錯誤,但是怎麼會變成這樣,我思考好了一陣子,稍微有點結論。

如果SUnion發現傳入的key數量是0個,那麼它視為錯誤的話,可能回傳一個
error給我,我收到error還是得做錯誤處理。

所以一開始,這種就是不對的狀況,我應該在傳入method之前,事先檢查過slice的內容數量,若有問題就決定不繼續往下做,而不是責任交由給後面處置。

另一方面來說,如果要使用的method沒有error的回傳值,我也應該務必確保與檢查,傳入的值應該要正確或沒有問題,因為method並不會告訴我有沒有error發生,若有問題可能就是panic之類的噴出來了。

下篇要分享爆連線數量的經驗,當時可嚇死了一票看監控的人員


上一篇
Day5 .[重災經驗篇] gorutine與map的讀寫
下一篇
Day7 .[重災經驗篇] 爆連線問題,TCP ESTABLISHED 咬著不放
系列文
Let's Eat GO ! 實務開發雜談by Golang30

尚未有邦友留言

立即登入留言