[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167365#comment-14167365
]
Haohui Mai 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.
Let's fix this. Personally I think a good native c++ interface still has its
merits -- as you've mentioned we have a lot of users in C++. It's difficult to
pass information (e.g., error messages) in the wrapping. Clients might want a
simple user interface.
There are C++ libraries (e.g., leveldb, qt) only offer native c++ interfaces.
We can follow their approaches. If you're uncomfortable with the APIs for now,
what about declaring it as unstable and giving no compatibility guarantees?
[~cmccabe], if you don't mind, maybe I can take a crack on this?
> 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: Bug
> 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)
