iron_go icon indicating copy to clipboard operation
iron_go copied to clipboard

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

Open deckarep opened this issue 11 years ago • 4 comments
trafficstars

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.

deckarep avatar Dec 07 '13 17:12 deckarep

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 avatar Dec 07 '13 21:12 edsrzf

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.

deckarep avatar Dec 07 '13 22:12 deckarep

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

hjr265 avatar May 30 '14 05:05 hjr265

Oops! I just realized that there is a pull request for that already. Really sorry for bumping this old issue.

hjr265 avatar May 30 '14 05:05 hjr265