-
-
Notifications
You must be signed in to change notification settings - Fork 64
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
error handling w/o error slices and more #157
Conversation
This will take some time to review! :) |
Another concern that I am not yet tackling neatly is how a user can easily work with those returned errors because errors.As or errors.Is would detect there to be a cyclic reference error inside of that slice but you would also need a (preferrably easy) way to check if there are also other errors inside of that multi error. EDIT: |
makes the user handle errors differently the user, depending in their requirement, will either want or not want to resolve circular references. In case that the user decides to forbid resolving circular references, they will handle returned errors as such and they will not need to pick out any specific error from the returned multi error. Changing this default removes the need to actually check if one of the errors is the circular reference error.
Allowed circular reference resolving by default This makes the user handle errors differently. Changing this default removes the need to actually check if one of the errors is the circular reference error. in case a user wants to unwrap the MultiError, they should use a type assertion like this, I prefer not to bloat the public api with helper functions for error handling doc, err := LoadDoc()
if err != nil {
if errs, ok := err.(interface{ Unwrap() []error }); ok {
for _, e := range errs.Unwrap() {
fmt.Println(e)
}
}
} |
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
dunno what problems github currently has. Tests will fail because of data races but not due to actual tests failing.
same PR for my forked main branch: |
The tests just timeout? |
the errors looked like something weird from the GitHub runner but not like the actual Go test timeout of 20 minutes was reached (which I configured). |
might be that the runner or assignment to a GitHub runner timed out |
first research indicates that high cpu load for an extended period of time might have caused the GitHub runner to have been canceled (crypto miner detection or whatever). |
seemingly splitting the tests and removing timeouts helps(?) |
You should remove the |
will merge main branch into this branch once #162 is merged into main. |
slightly confused as to why this happened:
running this locally returned 62 again. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #157 +/- ##
==========================================
- Coverage 99.80% 99.66% -0.14%
==========================================
Files 148 152 +4
Lines 10619 17810 +7191
==========================================
+ Hits 10598 17750 +7152
- Misses 21 39 +18
- Partials 0 21 +21
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
should be used as reference, errorutils might be replaced with simply errors.Join |
poc implementation for #155 & #117
benchmarks were broken of which only one is left broken.
Some findings that I had during my implementation is that there seem to be some Setter methods defined for value receiver methods (and some more staticcheck warnings)
And you need to dig pretty deep in order to find your configuration defaults. (http.Get for example)
Overall great test coverage which helped a lot.
Edit, just saw the other PR:
#123 seems to wrap errors already.
This PR does slightly more.
It allows to control circular reference errors at document object contruction for the top level library.
TODO:
use a tool like https://pkg.go.dev/golang.org/x/exp/cmd/gorelease to see how much the api changed.