Does it make sense to iron_go api to return an error when no messages in the queue? #8

deckarep opened this Issue Dec 7, 2013 · 4 comments


None yet

3 participants


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.


@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment