Nonthrowing constructors for C++ binding of Rust std types

[maurer]

In some constructors, cxx uses exceptions to indicate failure. Many codebases specifically disable exception support for C++ for a variety of reasons (Firefox and Chromium amongst them).

In the long term, I would hope we could design a system that would allow these errors to be caught in both exception-based C++ and -fno-exceptions code, but for now even just printing the error message and abort()ing would at least be a start.

In summary:

• Do you have plans to support non-exception C++, or would you be open to such plans?
• In the short term, would you be open to a configuration switch that would generate fatal errors rather than throwing an exception?

[dtolnay]

I am open to considering plans for this but I am not familiar with the C++ ecosystem. Can you link to how some other libraries handle supporting both exceptions and no-exceptions codebases?

[adetaylor]

Here's how I did this as a gross hack for experimental purposes. I've no idea if this works more generally, which is why this isn't a PR.
master...adetaylor:no-exception-mode
(The structopt change is unrelated and I can't remember why that was necessary)

I don't know if __EXCEPTIONS can universally be relied upon with any toolchain - I got it from here - https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

[dtolnay]

I would be willing to accept a PR like that to at least make the code compilable, and we can defer designing how to expose those constructors in a better way.

It looks like the clang spelling of the same thing is __has_feature(cxx_exceptions).

One note is I would lean toward assuming exceptions unless there is evidence otherwise, i.e. unlike adetaylor's patch which defaults to no exceptions on toolchains that wouldn't ever set __EXCEPTIONS.

[adetaylor]

Thanks. Clang defines the same __EXCEPTIONS macro.

One note is I would lean toward assuming exceptions unless there is evidence otherwise, i.e. unlike adetaylor's patch which defaults to no exceptions on toolchains that wouldn't ever set __EXCEPTIONS.

Makes sense. I don't think we can do this with standard C++ facilities. As far as I can tell (from the macros defined in our Chromium toolchain, at least) there are various clues about the presence of exceptions but no clues about the absence. For example gtest seems to use this:

#define GTEST_HAS_EXCEPTIONS (__EXCEPTIONS && __has_feature(cxx_exceptions)). libcpp also #defines _LIBCPP_NO_EXCEPTIONS on the basis of __EXCEPTIONS and __has_feature(cxx_exceptions) so that seems to be the way to go, if we want to use standard C++ facilities.

However: almost by definition, anyone wanting a no-exceptions mode is using a custom toolchain, and can define their own macro in the C compiler invocation. So we could just use #ifdef _RUST_CXX_NO_EXCEPTIONS or similar if you like?

[dtolnay]

Opened #101 to recognize RUST_CXX_NO_EXCEPTIONS. For printing I just put std::cerr << "Error: " << msg << ". Aborting." << std::endl followed by std::abort()... lmk if it looks fine or if there's anything else you would like in there.

[adetaylor]

Thanks very much David! That works nicely.

[maurer]

With regards to other C++ codebases supporting similar dual handling, the big one I'm aware of is Boost. Boost will suppress exceptions if BOOST_NO_EXCEPTIONS is defined. By default, it will convert them into an assert message and an abort. It also has the additional configuration knob BOOST_CONTAINER_USER_DEFINED_THROW_CALLBACKS which allows the user to provide alternate implementations for throw to do some alternate kind of error reporting.

The STL does this partially by defining alternate noexcept APIs for many of its functions, e.g.
void* operator new (std::size_t size, const std::nothrow_t& nothrow_value) noexcept;

For the constructor case you've got currently, the usual way to make this have handleable errors is to separate construction and initialization, where the constructor is infallible, but an initialization step can potentially generate an error (in this case just returning an error code), which must be checked by the caller.

In other cases, where we want to translate a Rust Result<T, E>, we can translate it to something similar to std::expected<T, E> (actual std::expected is still not standardized, it is in the running for C++23, but we could use a similar class).

This leaves the question of whether the signatures/APIs should look different in exception/non-exception mode, or both should be exported.

For non-constructor functions, we could use std::nothrow_t& overloads to allow both to exist within the same codebase, and simply disable the non-noexcept functions in the no exception build. This would be more cumbersome, but would both allow exception users to use error codes when desired, and allow testing of all APIs from a single build. We would still need the additional initialization APIs for fallible constructors, as those cannot return an error code.

The other option I can see is to build different APIs depending on a configuration flag, so the exceptionful API would look roughly like what you're developing now, and when exceptions are disabled, we would switch over. This would still require separation of initialization from construction (though you could call the initializer from a constructor when exceptions were enabled) and would require macro usage to select different return types depending on compilation mode. However, this mode is likely to be substantially more user friendly, as users don't need to repeatedly pass dummy parameters.

[na-g]

An additional data point here, from the isocpp.org April 2019 survey (Q11): only 52% of surveyed participants were allowed to freely use exceptions anywhere in their C++ projects, while about 22% were forbidden from using exceptions anywhere. Two other methods are additionally reported: error codes, and result types. They similarly have splits that show how opinionated C++ projects can be about error handling. Of the three methods though, it should be noted that only exception free code is enforced by project wide compiler flags, reducing the opportunity for allowances made at the edge for libraries with differing opinions.