[
https://issues.apache.org/jira/browse/HDFS-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172508#comment-15172508
]
James Clampffer commented on HDFS-9699:
---------------------------------------
Seems like a good improvement. Nitpick (not a blocker) about the error
messages:
{code}
return Error(Status::Exception("Uncaught non-exception", ""));
{code}
It might be better to word this as something like "Uncaught value not derived
from std::exception" in order to make it a little more precise. I think that
makes it a little easier to infer a {code} catch(...) {code} block for people
familiar with C++. Any opinion?
I think down the road we also need some catch blocks closer to where the
exceptions are actually being emitted. IIRC the asio docs specify that some
operations throw specific exceptions. That way the async C++ interface can
also have a no throw guarantee but if client handlers chose to throw they can
still propagate out as expected.
> libhdfs++: Add appropriate catch blocks for ASIO operations that throw
> ----------------------------------------------------------------------
>
> Key: HDFS-9699
> URL: https://issues.apache.org/jira/browse/HDFS-9699
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: James Clampffer
> Assignee: James Clampffer
> Attachments: HDFS-6966.HDFS-8707.000.patch,
> HDFS-9699.HDFS-8707.001.patch, cancel_backtrace.txt
>
>
> libhdfs++ doesn't create exceptions of its own but it should be able to
> gracefully handle exceptions thrown by libraries it uses, particularly asio.
> libhdfs++ should be able to catch most exceptions within reason either at the
> call site or in the code that spins up asio worker threads. Certain system
> exceptions like std::bad_alloc don't need to be caught because by that point
> the process is likely in a unrecoverable state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
