hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7207) libhdfs3 should not expose exceptions in public C++ API
Date Fri, 10 Oct 2014 20:46:33 GMT

    [ 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

from https://issues.apache.org/jira/secure/attachment/12666481/HDFS-6994.patch :
+ * 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
+ *                  If last operation finished successfully, the returned message is undefined.
+ */
+const char * hdfsGetLastError();

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

View raw message