[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169588#comment-14169588
]
Haohui Mai commented on HDFS-7207:
----------------------------------
bq. it has no return value, what if the std::bad_alloc is throw in
constructor?
The interface can throw no exceptions at all, even {{std::bad_alloc}}. A static
call is sufficient to take care of it. For example:
{code}
static Status Create(FileSystem **fsptr);
{code}
Note that the {{Status}} object also allows getting the users to get the
information in the form of strings.
bq. but a shared_ptr of DBImpl is still need to keep in Iterator to avoid the
core dump if the user continue to use the iterator after delete db
The expected behavior is to crash right at the line of {{delete db}}. It avoids
any uses of dangling iterators. Obviously the code needs to keep a refcount
somewhere, but that way the code does not need to expose {{std::shared_ptr}} in
the interface.
> 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)
