[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169078#comment-14169078
]
Zhanwei Wang commented on HDFS-7207:
------------------------------------
bq. Since the current libhdfs3 C++ interface you have proposed exposes so many
internal things, this will make it almost impossible to change anything after a
release.
All internal things are included in {{hdfs::internal}} namespace, and will not
expose in the header files for users as API. Would you please point out which
internal things are exposed? I'd like to fix them.
If the API class has to reference the internal object, I introduce a forward
declaration and add a point of internal object in the private section of API
class.
One exception is {{hdfs::internal::shared_ptr}} used in {{FileSystem}}, which
was NOT in my original patch, I wrapped it hold a pointer of
{{FileSystemImpl}} and do not use {{shared_ptr}} in the interface to avoid to
expose {{hdfs::internal::shared_ptr}}.
Exposing {{shared_ptr}} and {{std::string}} in API may introduce binary
compatible issue. Since different C++ compiler and runtime may have the
different incompatible ABI. To avoid this, the best way is to only use the C
type in API.
> 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)
