Closed benblack86 closed 6 years ago
So I didn't realize this, but the redis interface has both get
and getOption
methods. So technically you can already do it either way with redis.
Personally I feel like the way the memcached client does it makes sense for redis (having get
return an option and just get rid of getOption
), but not for http, where "get" is not really key/value get.
This does bring up a bigger issue of how clients handle responses in a way that's consistent across protocols. In particular, "should protocol errors be encoded as exceptions in failed Futures/Callbacks?" . And a followup question is given a protocol, what kinds of responses are considered errors?
For question 1, I think it depends. For example, I definitely think a memcached get
miss should be returned as a None
option, not as something like NoDataException
, but maybe a 404 for a http get should be a NotFoundException
?
For question 2, again I think there's no simple answer, but I do believe we can try to categorize every type of error across protocols:
Once we've properly categorized responses, then we can determine which ones should become exceptions, and maybe decide if we can have some common exceptions shared across protocols.
I think for the particular example I raised, updating the Redis client so get
returns an option would make me happy. I'll work on that first.
I'm going to punt on the extra questions as I don't think there is a simple answer :)
More of a question for @DanSimon
If sending a get request to redis you should generally use
mapTry
:However, memcache returns an option so
map
is sufficient unless you want to handle the case where a incorrect response is sent by memcached.Any particular reason for this? Should we make it consistent? Looks like http follows the same style as redis. Which style is the best?