accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-2133) [API] Better exceptions for invalid table/namespace arg
Date Fri, 28 Mar 2014 21:07:14 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christopher Tubbs updated ACCUMULO-2133:
----------------------------------------

    Issue Type: Sub-task  (was: Improvement)
        Parent: ACCUMULO-2589

> [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.2#6252)

Mime
View raw message