You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Yulin Niu <yu...@gmail.com> on 2020/10/18 12:45:18 UTC
[DISCUSS] the IA annotation on hbase client exceptions
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
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by Sean Busbey <bu...@apache.org>.
That sounds good to me.
On Tue, Oct 27, 2020 at 9:00 AM 张铎(Duo Zhang) <pa...@gmail.com> 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 <bu...@apache.org> 于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) <pa...@gmail.com>
> > wrote:
> > >
> > > Let's wait for a while to see if there are other feedbacks.
> > >
> > > Yulin Niu <yu...@gmail.com> 于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) <pa...@gmail.com> 于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 <bu...@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 <yu...@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Sean
> >
--
Sean
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <bu...@apache.org> 于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) <pa...@gmail.com>
> wrote:
> >
> > Let's wait for a while to see if there are other feedbacks.
> >
> > Yulin Niu <yu...@gmail.com> 于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) <pa...@gmail.com> 于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 <bu...@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 <yu...@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
> > > > > >
> > > > >
> > > >
> > >
>
>
>
> --
> Sean
>
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by Sean Busbey <bu...@apache.org>.
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) <pa...@gmail.com> wrote:
>
> Let's wait for a while to see if there are other feedbacks.
>
> Yulin Niu <yu...@gmail.com> 于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) <pa...@gmail.com> 于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 <bu...@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 <yu...@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
> > > > >
> > > >
> > >
> >
--
Sean
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Let's wait for a while to see if there are other feedbacks.
Yulin Niu <yu...@gmail.com> 于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) <pa...@gmail.com> 于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 <bu...@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 <yu...@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
> > > >
> > >
> >
>
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by Yulin Niu <yu...@gmail.com>.
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) <pa...@gmail.com> 于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 <bu...@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 <yu...@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
> > >
> >
>
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
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 <bu...@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 <yu...@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
> >
>
Re: [DISCUSS] the IA annotation on hbase client exceptions
Posted by Sean Busbey <bu...@apache.org>.
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 <yu...@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
>