4 ms·

(Author, here.) I also recommend garyburd/redigo. I especially like the API. Instead of adding methods for every Redis command, redigo uses a single Do() method

(Author, here.) I also recommend garyburd/redigo. I especially like the API. Instead of adding methods for every Redis command, redigo uses a single Do() method and then has several "type helper" methods that allow you to convert the response to various types simply by wrapping Do(): value, err := redis.String(client.Do("GET", "mykey")) Of course, this means you need to know about every command's response type and adds an extra (if small) level of verbosity, but in practice it fits very well with Go's philosophy of handling errors often and early. So, for instance, you're encouraged to handle the possibility that your key doesn't exist rather than barreling ahead with an empty string.

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 ago
  The 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.

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 ago
The 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.