[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602922#comment-13602922
]
Jean-Marc Spaggiari commented on HBASE-8112:
--------------------------------------------
I thought about catching the exception too but if we do so, we will have to
change the signature in the interface too to not keep the throws there. If we
don't change the signature, people might be confused by that and expect some
exceptions when none can be thrown.
{code}
public Object[] batch(final List<? extends Row> actions)
throws InterruptedException, IOException {
{code}
This method will throw a RetriesExhaustedWithDetailsException whatever
exception it will have found in the execution process. But if any is thrown,
then you will not get the results. If we change it to catch the exception
internaly and always return the results, we are changing the method behaviour,
which might break some already existing user usecases.
{code}
public void batch(final List<?extends Row> actions, final Object[] results)
throws InterruptedException, IOException {
{code}
We already have this one also, which will always populate the results and will
also throw an exception if required.
So personally, I think we should put the former deprecated and document it to
explain why the later should be used and how.
Alternative option is to better document the former to explain that if an
exception occurs, nothing will be returned, but everything might still be
processed and client application will have no way to know what has been
processed and what has not been...
Ultimately, we should also allow the later to be called with "null" as the
results in case someone don't want to retrieve the results. That can improve
the performances by avoiding some objects creations and loops (I can provide a
patch as an example).
> Deprecate HTable#batch(final List<? extends Row>)
> -------------------------------------------------
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Priority: Minor
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List<? extends Row>){code} and
> refer to the following method:
> void batch(final List<?extends Row> actions, final Object[] results) throws
> IOException, InterruptedException;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
