[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163818#comment-14163818
]
Colin Patrick McCabe commented on HDFS-7207:
--------------------------------------------
Just to get everyone up to speed here, the current version of libhdfs3 that has
been posted has two APIs. One is the C API described in {{hdfs.h}}. The other
is a new C\+\+ API.
It seems like those who don't want exceptions could simply use the the
{{hdfs.h}} API. That API will always be better than a C\+\+ API anyway, since
it will be practically impossible to keep the C\+\+ ABI stable across versions.
If you want to try, you can read this:
https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
There are other advantages to using hdfs.h: it allows you to swap in
{{libhdfs}} or {{libwebhdfs}} when needed.
That being said, I have no objections to removing exceptions from the libhdfs3
public C\+\+ API. But I also have no plans to use or maintain that 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: Bug
> Reporter: Haohui Mai
> Priority: Blocker
>
> 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)
