I think we should change what they throw directly and label it incompatible. I think this is in line with our previous expectation setting about how we'll handle mistakes in the API.
That change would be source incompatible but would still be binary compatible. I think we should do it in a major release. esp since there's not a way in Java to say "this deprecation is just about the thrown exceptions" and it will be awkward to write code that is source compatible with the existing api and with the exception removed. On Sat, Nov 28, 2020, 22:07 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > In HBASE-24966, we found that in AsyncTableRegionLocator, we accidentally > declared 3 methods > > getStartKeys > getEndKeys > getStartEndKeys > > to throw IOException directly. > > This should be a copy paste mistake, as typically, for a method which > returns CompletableFuture, the exception should be returned through the > CompletableFuture, and this is exactly the behavior of these methods. > > So the actual problem is only that we have a wrong method signature. but > since this interface is IA.Public, and it has already been included in > several releases, according to our compatibility rule, we can not just > remove the throws part from the method. Instead, we need to deprecate them > and create new methods. But there will be another problem that we want to > align the method names between the sync and async client, so if we change > the names of the methods, we'd better also change the name of methods for > sync client, which will make our users do more unnecessary work. > > So here I want to discuss that, since we all know that, this is a mistake, > and the methods will never throw IOException directly, is it OK for us to > just remove the throws part and tell users directly that this is a mistake, > and release it in the next minor release or a major release as an > incompatible change? > > Thanks. >
