Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 28 Mar 2014 21:07:14 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12687327.1388868732570.27377.1396040834645@arcas>
In-Reply-To: <JIRA.12687327.1388868732570@arcas>
References: <JIRA.12687327.1388868732570@arcas>
Subject: [jira] [Updated] (ACCUMULO-2133) [API] Better exceptions for
 invalid table/namespace arg
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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)