[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167479#comment-14167479
]
Colin Patrick McCabe commented on HDFS-7207:
--------------------------------------------
bq. Please note that the API needs to convey information more than the error
number, for example, stack traces. The Status object should be able to contain
a customized message.
This is easy to fix by adding a thread-local variable containing a string that
can be set by libhdfs operations.
In fact, the original patch for libhdfs3 already implements this by providing
an hdfsGetLastError function.
from https://issues.apache.org/jira/secure/attachment/12666481/HDFS-6994.patch :
{code}
+/**
+ * Return error information of last failed operation.
+ *
+ * \@return A not NULL const string point of last error information.
+ * Caller can only read this message and keep it unchanged.
No need to free it.
+ * If last operation finished successfully, the returned
message is undefined.
+ */
+const char * hdfsGetLastError();
{code}
I didn't call it to this patch because I wanted to get a clean run on trunk
Jenkins, and we haven't added {{hdfsGetLastError}} in trunk. But you could
easily call hdfsGetLastError in the Status constructor, and store that error
string for later.
bq. Why HdfsFileSystem has to be a shared object?
I do not want HdfsFileSystem to be destroyed while Input or Output streams
still hold a reference to it. These streams need to hold a reference to it in
order to perform their operations. But a shared_ptr can only do this if all
access is through the shared_ptr.
Since there will usually be only one HdfsFileSystem, the overhead of using a
{{shared_ptr}} seems extremely minor. The ability to prevent reference leaks
is one of the key features that make the C\+\+ interface better than the C
interface. If we force the user to manage this on their own, they might as
well just use the C interface at that point.
> libhdfs3 should not expose exceptions in public C++ API
> -------------------------------------------------------
>
> Key: HDFS-7207
> URL: https://issues.apache.org/jira/browse/HDFS-7207
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Haohui Mai
> Assignee: Colin Patrick McCabe
> Priority: Blocker
> Attachments: HDFS-7207.001.patch
>
>
> There are three major disadvantages of exposing exceptions in the public API:
> * Exposing exceptions in public APIs forces the downstream users to be
> compiled with {{-fexceptions}}, which might be infeasible in many use cases.
> * It forces other bindings to properly handle all C++ exceptions, which might
> be infeasible especially when the binding is generated by tools like SWIG.
> * It forces the downstream users to properly handle all C++ exceptions, which
> can be cumbersome as in certain cases it will lead to undefined behavior
> (e.g., throwing an exception in a destructor is undefined.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
