Re: Question about Guava's RateLimiter API design

[Chris Povirk]

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]

That's really helpful to know. Thanks for the response Chris!