[
https://issues.apache.org/jira/browse/ACCUMULO-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840317#comment-13840317
]
Sean Busbey commented on ACCUMULO-1965:
---------------------------------------
bq. In essence, I think: if we document what are valid arguments, and you're a
consumer of that API, then you need to ensure that the arguments you provide
are valid arguments. This is true for anything using the API... whether you are
an end user, or a wrapper.
+1 I agree with Christopher. Consider some example uses of our API.
with additional exception types:
{code}
public void userProvidedTable(String table) {
try {
connection.tableOperations().create(table);
// ...
} catch (InvalidTableNameException exception) {
// Provide user feedback about problem
}
}
{code}
with an validity helper method
{code}
public void userProvidedTable(String table) {
if (!(TableOperationsHelper.isValidTableName(table))) {
// Provide user feedback about problem
}
connection.tableOperations().create(table);
// ...
}
{code}
The validity of the table name isn't an unexpected situation that you can't
know before you make the call (like e.g. if the table will exist when Accumulo
goes to actually make the table).
> Invalid table names (& namespaces) should have dedicated error codes
> --------------------------------------------------------------------
>
> Key: ACCUMULO-1965
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1965
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Reporter: John Vines
>
> To improve the client API, we should minimize the number of exceptions that
> require String parsing to determine the exception type. Table naming errors
> is one of them.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
