That sounds good to me. On Tue, Oct 27, 2020 at 9:00 AM 张铎(Duo Zhang) <[email protected]> wrote: > > I like what you propose and we do have this usage in our CP methods. We may > reference IA.Private classes in CP methods and what we tell users is that > you can just reference it and pass it to other CP methods as a whole, > please do not call its method. > > But this is a much larger topic than the title of thread. > > So I suggest we just keep the exception type IA.Private for now, we can > open another issue or discussion for the new IA.LimitedPrivate annotations. > > Thanks. > > Sean Busbey <[email protected]> 于2020年10月22日周四 下午10:25写道： > > > Why are we not just leaving things IA.Private? What are we trying to > > enable? Don't downstream clients just need DoNotRetryIOException and > > IOException? > > > > If we're going to go with LimitedPrivate is it worth defining a LP > > audience that means "you can refer safely to this class name but you > > should not instantiate or extend the class and you should not call any > > methods on it"? something like LimitedPrivate(OPAQUE) and then we > > could also use that to annotate classes that are not IA.Public but > > appear in IA.Public method signatures? > > > > Maybe something like EXCEPTION_HANDLING would be clearer though. The > > existing LP audience of CONFIG is kind of like that, where we say the > > fully qualified classname needs special handling because it could > > appear in configuration files. > > > > On Thu, Oct 22, 2020 at 1:42 AM 张铎(Duo Zhang) <[email protected]> > > wrote: > > > > > > Let's wait for a while to see if there are other feedbacks. > > > > > > Yulin Niu <[email protected]> 于2020年10月21日周三 上午11:58写道： > > > > > > > So, we introduce a new Annotation IA.LimitedPrivate(Exception) to > > decorate > > > > the exceptions, which are free to catched and propagated by users, but > > > > should not be created by users themselves. > > > > > > > > 张铎(Duo Zhang) <[email protected]> 于2020年10月18日周日 下午10:08写道： > > > > > > > > > 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 <[email protected]> 于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 <[email protected]> > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Sean > >
-- Sean
