You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we catch and abort on unwinding across the FFI boundary in either direction; it's left to the user to communicate all failures via ordinary return values or out-parameters.
It would be nice if C++ exceptions were exposed to Rust as an idiomatic Result error value. For C++ functions that are declared in the bridge as returning a Result, we would not abort on exceptions but instead marshal them across as some kind of cxx::Exception object.
In both cases, long term we would want the translation to be customizable because not all codebases use exceptions; some would prefer a mapping of Rust Result to Leaf or Outcome. Some thoughts in #16.
The text was updated successfully, but these errors were encountered:
I started putting together a design for the exception-to-Result direction of this.
I'm trying to leave open the possibility of different codebases having different try-catch logic for extracting messages from exceptions, while still providing a reasonable default conversion. I think there will be a way for us to accommodate this with an expression SFINAE that looks like the following:
// union with the same layout as std::result::Result<T, cxx::Exception>
rust::Result<T> result;
trycatch(
[&] {
new (&result) rust::Result<T>(the_function(args...));
},
[&](rust::Exception e) noexcept {
new (&result) rust::Result<T>(std::move(e));
});
return result;
In this implementation, CXX provides a default try-catch based on std::exception::what but the user can replace it by providing any function template with this signature in their header:
Since our generated code includes the user's header before our default provided trycatch implementation, according to https://timsong-cpp.github.io/cppwp/basic.scope.hiding their trycatch function hides the dummy trycatch struct and the expression SFINAE makes our default provided one not exist.
As an example in Folly's case the codebase might use this which provides more type information:
Currently we catch and abort on unwinding across the FFI boundary in either direction; it's left to the user to communicate all failures via ordinary return values or out-parameters.
It would be nice if C++ exceptions were exposed to Rust as an idiomatic
Result
error value. For C++ functions that are declared in the bridge as returning a Result, we would not abort on exceptions but instead marshal them across as some kind ofcxx::Exception
object.Conversely, Rust functions that are declared as returning a Result could transmit failures as an exception on the C++ side.
In both cases, long term we would want the translation to be customizable because not all codebases use exceptions; some would prefer a mapping of Rust
Result
to Leaf or Outcome. Some thoughts in #16.The text was updated successfully, but these errors were encountered: