-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add exception guard to FFI boundary. #1212
Conversation
This uses function try blocks to prevent C++ exceptions from propagating across the FFI boundary. Some functions which return direct values (rather than error codes) and do not throw are left as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent stuff. Thanks @dewyatt !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be nice to add some tests that throw various exceptions and check that everything works as expected
b27cc72
to
56cd0ff
Compare
Added some tests. It only tests against a single FFI function really but it does test a few different exception types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks, @dewyatt. But let's wait for @antonsviridenko comments as he was first to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@antonsviridenko Feel free to rebase and merge once there are two or more approvals. |
This uses function try blocks to prevent C++ exceptions from propagating
across the FFI boundary. Some functions which return direct values
(rather than error codes) and do not throw are left as-is.
For now it just prints directly to
stderr
and uses a format similar toRNP_LOG
, which I think is a good compromise considering that it should be a very rare occurrence.Fixes #839