[FEA] Add CMake Option to Disable Exceptions

[JieRen98]

I'm working on a project that requires the use of the C++ compile option -fno-exceptions to optimize my library's performance and reduce binary size.

When compiling RMM with -fno-exceptions, I encountered a compilation error because code paths like RMM_EXPECT explicitly or implicitly use throw (e.g.,

rmm/cpp/include/rmm/detail/error.hpp

Line 65 in 5072785

: throw _exception_type{std::string{"RMM failure at: "} + __FILE__ + ":" + \

).

Could the RMM library implement a CMake option (similar to SPDLOG_NO_EXCEPTIONS in spdlog) to conditionally disable exception-throwing behavior and allow for compilation with -fno-exceptions?

[bdice]

@JieRen98 RMM relies on C++ exceptions to convey problems like out-of-memory errors back to applications using RMM.

What design would you propose for this? A special return value for calls that error? Ignoring errors entirely? Would you be interested in contributing a pull request after we discuss possible designs?

[JieRen98]

My project primarily involves C libraries, where I use an extern "C" wrapper to export a C API that utilizes some RMM features. These C APIs are, in turn, consumed by upstream libraries.

For my specific use case, I only require that the program prints necessary error messages and terminates upon encountering a critical error.

I would like to contribute, but I don't have a definitive proposal. Perhaps a simple approach—such as having functions return a NULL pointer (similar to malloc) on a bad allocation—would be sufficient. I don't know... What do you think?

[JieRen98]

I believe that supporting both exception-enabled and exception-disabled builds is a crucial feature. Many libraries (especially C libraries) do not support or require exception handling. By removing exception support, one can achieve a slight performance improvement and a significant reduction in binary size. What do you think?

[bdice]

I think you can use try { ... } catch (...) { ... } blocks in your extern "C" wrappers to put a firewall around potentially exception-throwing code.

Exceptions are a core part of RMM's C++ design, so I don't expect this to change in our C++ code. Simply ignoring exceptions would not be safe. If we added a C API for RMM, I would probably recommend that we provide error codes as a return value, rather than using null pointers to indicate an allocation failure.

Would you be interested in helping with the design of an official C API? We have had other requests for this, and I'd like to see what you are currently doing to wrap RMM in C. Is this a public project?

[JieRen98]

Yes, I agree that confining the try-catch blocks to the extern "C" wrappers would ensure the program's reliability in the current situation.

Personally, I have a strong preference for binary optimization—I typically disable exceptions and strip symbols in my projects to achieve the smallest possible executable size.

I would be happy to assist with the design and development of official C APIs and the mechanisms required to support an exception-disabled configuration.

My current work involves developing sparse direct solvers and optimizing/hijacking various runtime functions (such as those similar to cudaMalloc). Both of these projects export C APIs but are written in C++. While they are not public, I am certainly open to discussing my specific use cases with you privately.