-
Notifications
You must be signed in to change notification settings - Fork 157
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
feat: Allow the build to be configured in "fail on error" mode #687
Conversation
This PR does not yet enable the newly introduced functionality in CI for two reasons:
|
@paulgessinger It looks like the macOS build is misbehaving. I think we already observed a similar issue before? |
Codecov Report
@@ Coverage Diff @@
## master #687 +/- ##
==========================================
+ Coverage 49.00% 49.03% +0.03%
==========================================
Files 331 331
Lines 16549 16549
Branches 7723 7725 +2
==========================================
+ Hits 8110 8115 +5
- Misses 3009 3013 +4
+ Partials 5430 5421 -9
Continue to review full report at Codecov.
|
…Logger in general
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, let's override the coverage report.
This PR enables the Acts logger to be configured in such a way that all log messages above a certain debug level (typically WARNING or ERROR) cause an exception to be thrown.
This is useful because Acts has a certain number of non-fatal error scenarios, which should not crash real-world physics reconstruction but indicate suspicious behavior that we will usually want to catch in automated testing (where we can control the inputs and make sure that non-fatal errors do not occur "by chance").
Throwing an exception on logging did not compose well with the
Logger::OutStream
mechanism, which would emit logs in its destructor, so after some discussion with @paulgessinger I decided to fix this by removing this mechanism and reworking the logger API in a much simpler direction. After all, logging is not meant to be fast, so passing logs asstd::string
s is okay as long as there's a way for the caller to avoid generating thestd::string
when it's not going to be printed.Since Logger is not documented to be part of the public Acts API, I do not consider this API rework to be a breaking change.
Fixes #482 .