2 ms·
That looks really verbose. Also, am I correct in thinking that redis.Integer(client.Do("GET", "mykey")) would be an error, even if you've previously stored a in
by eurleif 12y ago
That looks really verbose. Also, am I correct in thinking that redis.Integer(client.Do("GET", "mykey")) would be an error, even if you've previously stored a int value in the key? If so, that seems like a trap.
How is this better for error handling? Why couldn't client.Get("mykey") signal an error in the same way, rather than returning an empty string?
- BarkMore 12y agoThe statement value, err := redis.Integer(client.Do("GET", "mykey")) sets the int variable "value" to the decimal integer stored in "mykey". The variable err is set to a non-nil value if the value cannot be parsed as a decimal integer, the key is missing, the key is not a redis string, the connection is broken or any other error. This method of error handling is convenient because the application only needs to check for one error. The alternative is to do something like: v, err := client.Do("GET", "mykey") if err != nil { // handle command error } p, ok := v.(string) if !ok { // handle error where p is not a redis string } i, err := strconv.ParseInt(string(p)) if err != nil { // handle parse error } There is no trap. If the connection to the server is healthy and the value stored for "mykey" is a decimal encoded integer, then redis.Integer(client.Do("GET", "mykey")) returns that integer.