Re: Question about Guava's RateLimiter API design

23 views
Skip to first unread message

Chris Povirk

unread,
Nov 29, 2021, 1:22:55 PM11/29/21
to Jonathan Halterman, guava-discuss
On Sun, Nov 28, 2021 at 7:25 PM Jonathan Halterman <jhalt...@gmail.com> wrote:
Hi Chris,

I had a quick question about the Guava's RateLimiter design: is there a reason why the blocking methods don't throw InterruptedException? I can see that they're meant to be uninterruptable, and that they maintain a thread's interrupt flag if interrupted, but is there a reason why they don't just throw InterruptedException?

Thanks,
Jonathan

Hi, Jonathan,

Fun question -- it's probably been many years since I thought about it.

It looks like what happened is that RateLimiter was written to replace some older libraries that didn't support interruption. (I wouldn't be surprised if those libraries just swallowed interrupts, so at least we improved upon that!) If we'd declared that we throw InterruptedException, we wouldn't have been able to migrate callers off those older libraries as easily.

Now, we did discuss additionally providing methods that throw InterruptedException, and quite possibly we should have done that at some point in the past ~10 years :) Nowadays, that would mean "acquire"+"acquireInterruptibly" (like Lock) though we could originally have chosen to invert that into "acquire"+"acquireUninterruptibly" (like most other APIs). It sounds like we omitted the methods because there was no immediate demand (and RateLimiter already has a large API), and we just never revisited. It would be interesting to do some research, like to see how many callers of acquire() already appear inside a catch() block that catches InterruptedException or a method whose throws `clause` permits InterruptedException. I don't expect us to soon, but it would be interesting....

--Chris

Jonathan Halterman

unread,
Nov 29, 2021, 2:27:42 PM11/29/21
to Chris Povirk, guava-discuss
That's really helpful to know. Thanks for the response Chris!
Reply all
Reply to author
Forward
0 new messages