-
-
Notifications
You must be signed in to change notification settings - Fork 208
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
Control whether exceptions include the call and C++ stack with a macros #868
Control whether exceptions include the call and C++ stack with a macros #868
Conversation
…cpp::exception use Shelter instead of Shield because e.g. the result of get_last_call() would not be protected long enough. rework exception_to_r_condition and rcpp_exception_to_r_condition so that they share the same code via a template
…y don't include call and cppstack when RCPP_DEFAULT_INCLUDE_CALL is defined to false
Codecov Report
@@ Coverage Diff @@
## master #868 +/- ##
==========================================
- Coverage 90.21% 89.99% -0.23%
==========================================
Files 70 71 +1
Lines 3261 3269 +8
==========================================
Hits 2942 2942
- Misses 319 327 +8
Continue to review full report at Codecov.
|
If you could, please consider writing submissions and commit message without emojis. |
Thanks for tieing it into #663. We'll take a look. At some point we may need a full grid documenting how |
I can do that, maybe this should be part of your contributions guidelines. |
I edited these last week and decided against making it a requirement, but the language I added was milder under Coding Style:
I am just asking you (as well as everybody else) rather gently to consider following existing style. Most people have no problem with that. |
I don't have a problem with that. |
Excellent. Now, as we're at style: We have one pending PR I'll likely merge soon. Do you want to rebase then, or would it be ok if I squash-merged this one? I prefer to keep the git graph tidy and narrow. |
Feel free to squash. |
Worked like a charm in reverse depends, and now part of Rcpp 0.12.17.3 -- so thanks! |
Thanks. |
…and remove the calls from Rcpp exceptions. closes #3662
…and remove the calls from Rcpp exceptions. closes #3662
Follow up to #663.
The idea is to have a general default for whether exceptions generated by Rcpp include the call stack or not.
Adding the
RCPP_DEFAULT_INCLUDE_CALL
which by default is defined totrue
in Rcpp. When it is defined to false such as above, the default forinclude_call
in Rcpp::exception is set to false, and the other exceptions, e.g.eval_error
don't include the call and c++ stack.Having this in place means that a package can globally decide not to include the call stack for all exceptions that are generated by Rcpp internal code, and also still be able to use
stop(...)
instead ofthrow Rcpp::exception(tfm::format(...).c_str(), include_call = false)
which is I believe the only way available after #663.The alternative to this PR would be to rework all other exception classes so that they also have the
bool include_call
setting.This is not necessary as these other exceptions are mostly thrown by Rcpp itself and so there is no opportunity to set the
include_call
argument in their constructors.