accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2133) [API] Better exceptions for invalid table/namespace arg
Date Wed, 10 Dec 2014 03:13:12 GMT


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:
>             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

This message was sent by Atlassian JIRA

View raw message