protobuf中的枚舉缺省值應該為UNKNOWN
(金慶的專欄)
proto3中的枚舉值為了與proto2兼容,要求缺省值固定為第1個,值為0。
proto2中并沒有規定對范圍之外的枚舉值的處理,
而proto3中已規定無定義的枚舉值反序列化后再次序列化保持原值。
lua pbc 中對無定義的枚舉值做了忽略處理,效果等同于變成缺省值。
希望未來版本能符合proto3的規定。
協議定義中添加新的枚舉值是常有的,客戶端服務器協議版本不同時,
就會出現無定義的枚舉值。
如果缺省值為UNKNOWN, 則所有新增或已刪除枚舉值都按缺省值處理就不會出錯。
缺點是要求所有枚舉值都要顯式賦值,不能使用缺省值了。
例如,原來定義為
enum LoginResult {
OK = 0;
ERR_SERVER_FULL = 1; // 服務器已滿
ERR_VERIFY_FAIL = 2; // 驗證失敗
ERR_MULTI_LOGIN = 3; // 重復登錄
}
多數情況下,僅需缺省OK就行了。
但是服務器再添加一個 ERR_NOT_READY, 客戶端因為使用舊版協議,
遇見ERR_NOT_READY最終返回缺省值 OK.
(金慶的專欄)
proto3中的枚舉值為了與proto2兼容,要求缺省值固定為第1個,值為0。
proto2中并沒有規定對范圍之外的枚舉值的處理,
而proto3中已規定無定義的枚舉值反序列化后再次序列化保持原值。
lua pbc 中對無定義的枚舉值做了忽略處理,效果等同于變成缺省值。
希望未來版本能符合proto3的規定。
協議定義中添加新的枚舉值是常有的,客戶端服務器協議版本不同時,
就會出現無定義的枚舉值。
如果缺省值為UNKNOWN, 則所有新增或已刪除枚舉值都按缺省值處理就不會出錯。
缺點是要求所有枚舉值都要顯式賦值,不能使用缺省值了。
例如,原來定義為
enum LoginResult {
OK = 0;
ERR_SERVER_FULL = 1; // 服務器已滿
ERR_VERIFY_FAIL = 2; // 驗證失敗
ERR_MULTI_LOGIN = 3; // 重復登錄
}
多數情況下,僅需缺省OK就行了。
但是服務器再添加一個 ERR_NOT_READY, 客戶端因為使用舊版協議,
遇見ERR_NOT_READY最終返回缺省值 OK.