lua-resty-redis
lua-resty-redis copied to clipboard
Error handling in the example in the "Synopsis" section of README.markdown
I'm trying to understand the lack of connection handling during the return conditions in the example given in the package synopsis. I've no prior experience with Lua so maybe there's more going on implicitly than it obvious to someone without experience in the language.
Specifically, there seems to be some "normal" query conditions where the routine is returned from without either closing the connection or returning it to the pool. It would be useful to either have consistent treatment of the connection during the return conditions, or an explanation of the consequences of not closing the connection or returning it to the pool and what problems will result from this, or not.
I've annotates some of the returns. My comments below shouldn't be taken too literally since it is obviously not valid to "goto" over a local variable declaration, but are just indicators of the different types of conditions - bad data vs bad connection, etc - leading to returning from the routine.
...
server {
location /test {
content_by_lua_block {
local redis = require "resty.redis"
local red = redis:new()
red:set_timeouts(1000, 1000, 1000) -- 1 sec
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
ngx.say("failed to connect: ", err)
return -- HERE: Connection not succeeded: return may be the right thing to do.
end
ok, err = red:set("dog", "an animal")
if not ok then
ngx.say("failed to set dog: ", err)
return -- HERE: Is this a connection issue or a normal data condition? If just clashing keys then should it be a "goto done"?
end
...
local res, err = red:get("dog")
if not res then
ngx.say("failed to get dog: ", err)
return -- HERE: Is this the result of a connection issue?
end
if res == ngx.null then
ngx.say("dog not found.")
return -- HERE: Simple data not found, so should this be "goto done"?
end
...
::done::
local ok, err = red:set_keepalive(10000, 100)
if not ok then
ngx.say("failed to set keepalive: ", err)
return
end
...
}
}
}
Similar to #147, although it would be helpful to see some of the responses addressed concretely in the synopsis example.