[jira] [Commented] (ACCUMULO-2133) [API] Better exceptions for invalid table/namespace arg

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240581#comment-14240581 ] 

Christopher Tubbs commented on ACCUMULO-2133:
---------------------------------------------

The direction I'm thinking about this is that we can do Guava Precondition checks in the client code, which throw an IllegalArgumentException, before it hits the RPC layer. At the RPC layer, I'm fine with a server-side failure, manifest as an IOException (or equivalent report of a server-side exception) in the client. That should never happen, unless we have a bug in the client code, or somebody is talking directly to the RPC layer (which isn't public API, and use-at-your-own-risk), but it's still good to have reasonable server-side parameter checks.

We can put the Precondition calls in a common utility method used by both, so they don't diverge. I don't think the double-check matters in terms of cost. The server-side check is absolutely essential, but it's nice to get fast and informative failures in the client code. Doing server-side only check and translating the errors to get the same information is too prone to error. It's probably better to just check on both ends.

> [API] Better exceptions for invalid table/namespace arg
> -------------------------------------------------------
>
>                 Key: ACCUMULO-2133
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2133
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: Christopher Tubbs
>              Labels: api
>
> It has been discussed in IRC that we should have better exceptions exposed through to the public API when arguments for table names and namespaces are not valid for the given operation.
> One proposal was to create an InvalidNameException (or similar) to extend IllegalArgumentException when the provided string value is not appropriate for the operation. (One thing we should be careful about here, is making a separate exception or code for every nuanced and distinct reason why the argument is invalid.)
> Another suggestion was to make additional checked exceptions to handle these invalid argument values. This idea could be a separate exception or one that extends a base checked exception type (which currently doesn't exist for Accumulo).
> The current behavior (1.6.0-SNAPSHOT) is to throw an AccumuloException, often with a ThriftTableOperationException as its cause, which contains an INVALID_NAME code and a description specific to the cause. This is how the server sends the information back to the client when it fails argument checks. This ticket is regarding how the client should expose that exception back to the consumer of the client API.... because the current method of doing it is a bit clunky.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)