iron_go
iron_go copied to clipboard
Does it make sense to iron_go api to return an error when no messages in the queue?
Hey guys,
Wonderful api and platform you have here. I just wanted to see if you are okay with modifying the iron_go api to not return an error if no messages are in the queue. The logic is simple, if an error is returned than something went wrong, but having 0 messages in the queue is not technically an error, it should just simply result in an empty read with the payload being nil.
Also, wanted to ask if you supported any kind of blocking get when fetching a message in the queue? This way we don't have to poll in a tight loop.
I agree an error is not appropriate. However, we also aim to keep the library stable, so I think it's something users will have to live with for now.
There's a good chance there will be other reasons to break compatibility before too long, so at that point we'll make this change.
Ok no problem thanks for acknowledging. I completely understand about not making breaking changes...maybe for the next version.
Thanks again!
On Dec 7, 2013, at 1:36 PM, Evan Shaw [email protected] wrote:
I agree an error is not appropriate. However, we also aim to keep the library stable, so I think it's something users will have to live with for now.
There's a good chance there will be other reasons to break compatibility before too long, so at that point we'll make this change.
— Reply to this email directly or view it on GitHub.
@edsrzf Is it okay to declare this error as an exported var, may be something like
var ErrNoMsgs = errors.New("Couldn't get a single message")
The Get() func can then return this instead. That way that the user of this package can reliably tell which error actually happened.
Compatibility is really important! That is completely understandable.
But since this doesn't change the behavior of Get(), I can send this change as a pull request if that's okay.
Oops! I just realized that there is a pull request for that already. Really sorry for bumping this old issue.