[
https://issues.apache.org/jira/browse/HBASE-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592878#comment-13592878
]
Gary Helmling commented on HBASE-7997:
--------------------------------------
I'm not a huge fan of having all exceptions in the same package. I think in
general they make most sense in the packages where they most relate, where you
have some context.
I can understand why it was done the current way though, and agree that a
.regionserver package in the client module would be weird. Is there some other
package where these exceptions would naturally belong though? Like for
AccessDeniedException, I think that fits much more naturally in
o.a.h.h.security, whether it's in hbase-server, hbase-client, or hbase-common.
For all exceptions that don't depend on protobuf classes, I think they should
be in hbase-common. Any exceptions that do depend on protobuf bits could stay
in hbase-client or get reworked to remove the protobuf bits.
> One last set of class moves before 0.95 goes out
> ------------------------------------------------
>
> Key: HBASE-7997
> URL: https://issues.apache.org/jira/browse/HBASE-7997
> Project: HBase
> Issue Type: Task
> Components: Usability
> Reporter: stack
> Priority: Critical
> Fix For: 0.95.0
>
>
> hbase-server depends on hbase-client. Alot of exceptions are in hbase-client
> that are thrown by the hbase-server. Should these be in a common place
> instead of in hbase-client explicitly? Say in hbase-common? The client move
> put all of our exceptions into an exception package (apparently this is my
> fault). Is this a good idea? How many of these exceptions can we put beside
> the place where they are thrown?
> This issue is about spending a few hours looking at class locations before
> 0.95 goes out.
> Any other ideas?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
