[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167585#comment-14167585
]
Haohui Mai commented on HDFS-7207:
----------------------------------
bq. 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.
A slightly simpler (probably subjective) approach might be to wrap things in
the opposite way. That is, putting the error message / stack traces in the
{{Status}} object directly and let {{hdfsGetLastError}} to get the string. It
avoids copying the error message twice, once from the implementation to the TLS
and another from TLS to the returned {{Status}} object. What do you think?
bq. The ability to prevent reference leaks is one of the key features that make
the C++ interface better than the C interface.
If an Input / OutputStream is leaked than the corresponding FileSystem will
leak. I found the paradigm in leveldb quite helpful:
{code}
DB *db = DB::Open();
Iterator *it = db->(...);
delete db; // bails out because the iterator it has leaked.
{code}
That might allow the user to be more aware of the leaks. Maybe we can do
something similar?
> 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)
