[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165531#comment-14165531
]
Colin Patrick McCabe commented on HDFS-7207:
--------------------------------------------
bq. 5) If new application wants to use the feature in libhdfs3 but not
implemented yet (like encryption), it can use libhdfs or libwebhdfs with C
interface and switch to libhdfs3 later.
Let's say that my application only uses HDFS, so I feel confident using
libhdfs3. I use a libhdfs3-specific C\+\+ interface for my code. Suddenly
hdfs adds a new feature that (like encryption) that libhdfs3 doesn't support.
Now what do I do? I can't switch to a different library because the interface
I used was libhddfs3-only.
The only reasonable solution is to have a C\+\+ interface that all our
libraries support, or to have no C\+\+ interface. I am fine with either one of
those solutions.
I'm afraid that I am -1 on creating a C\+\+ interface unless we can support
that interface into the future. If we tell people that "New application
\[should\] usually prefer C interface instead of C\+\+ because C interface is
more stable" (as you have commented) then why have the C\+\+ interface in the
first place? We should not add code if we explicitly recommend that people
don't use it. It would just be creating a trap for people to fall into. And
then those people would show up on the mailing list, complaining when we broke
things in an upgrade. And we'd have to revert all the changes. It has
happened in the past for other components.
This is not a big deal when you have an internal tool (like libhdfs3 originally
was inside your organization) and you can coordinate a "flag day" when everyone
switches from one version to another. But in Hadoop we have to support old
versions for years. If we break APIs (or even worse, ABIs) across a minor
release, people get upset and they ask us to revert the change. 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.
In contrast, I would feel comfortable telling people to use the C\+\+ interface
I've posted here. We can support it into the future without any additional
effort beyond what we already exert to maintain the C API.
bq. I do not think it is necessary to add additional C++ interface for libhdfs
and libwebhdfs.
I am not the biggest C\+\+ fan, but shouldn't people have the right to program
in the language they choose? We have a lot of users of HDFS that are C\+\+,
starting with Impala and HAWQ.
Please take another look and let me know if there's anything I can improve.
Right now, the interface I posted seems strictly better than the previous
proposal. I think you should seriously consider it and let me know where it
falls short for you.
> 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)
