說明

利用...的寫法，可以在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之類的噴出來了。

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