I think IA.Public maybe over killed here for some exceptions. For example, the DoNotRetryIOException, we just want users to catch this exception, but usually we do not expect users to create this exeption by their own? But IA.Public means we can not change the public methods of the class, so we can not even remove constructors of the exception?
Maybe special IA.LimitedPrivate(Exception)? Which means you are free to catch and propagate the exception, but you should not create it by yourselves? Or use the special methods of the exception? Sean Busbey <bus...@apache.org> 于2020年10月18日周日 下午9:46写道： > My guess would be IA.Public is needed if the client can take action based > on the specific exception. So like the do not retry exception should be > public so folks know those IOExceptions that it's not worth baking off and > retrying. > > What's the specific list of public vs not? Why do you want the non public > ones to be public? What limitations are we putting on clients by keeping > them private? > > On Sun, Oct 18, 2020, 07:45 Yulin Niu <yulin.niu.2...@gmail.com> wrote: > > > Hi, guys: > > > > There are IA.Public and also IA.Private under the hbase-client > exceptions > > package, whether the IA.Private exceptions should be IA.Public? > > e.g.MasterRegistryFetchException, OutOfOrderScannerNextException > > ,RegionMovedException,RegionOpeningException > > And any others thing about the IA annotation on exceptions? > > FYI 2538 <https://github.com/apache/hbase/pull/2538> > > > > Thanks > > >
