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
Based on @prashantv's suggestions.
In the future, we should consider adding support for errtrace.Wrap to include key-value pairs as part of wrapping.
These values can be shown next to the function call in the trace, e.g.
This was a bit fuzzy in terms of details, but re-using slog fields was one of the options I was considering.
I'm keeping this as a low priority item, though, so as not to increase scope of this project at this time.
@StevenACoffman Agreed! We're hoping to keep this library lightweight and focused, and not turn it into a general "error utils" library.
Whether this feature goes into this library is still up for discussion, and it would have to be lightweight and composable (similarly to #106) if it did. An argument can be made that this is a logging-specific concern and it should go in a logerr package; nothing about this in set in stone at this time.
I was considering the possibility of switching over to using errtrace for my errors packages.
However, errtrace doesn't allow for creating new wrapping functions, only using its.
If you look in the link I sent, you will see a function WrapsSkip, where "skip" refers to skipping function calls in the stack trace. I don't see this kind of ability in errtrace other than to try to use its internal/pc package which does expose these abilities.
Activity
akshayjshah commentedon Nov 27, 2023
Is it reasonable to use
slogfields for this, or would we want to design our own API for key-value pairs?abhinav commentedon Nov 27, 2023
This was a bit fuzzy in terms of details, but re-using slog fields was one of the options I was considering.
I'm keeping this as a low priority item, though, so as not to increase scope of this project at this time.
StevenACoffman commentedon May 5, 2024
cockroachdb/errors has a ton of useful functionality... but is a very heavyweight and complicated library.
In #106 I added an interface so that the main value proposition of this library is composable with external custom error types.
I hope that allows this particular project to maintain a tighter focus.
abhinav commentedon May 5, 2024
@StevenACoffman Agreed! We're hoping to keep this library lightweight and focused, and not turn it into a general "error utils" library.
Whether this feature goes into this library is still up for discussion, and it would have to be lightweight and composable (similarly to #106) if it did. An argument can be made that this is a logging-specific concern and it should go in a logerr package; nothing about this in set in stone at this time.
Add TraceCaller interface for extensibility for #104 (#106)
gregwebs commentedon Feb 5, 2025
I have a package for attaching slog values and stack traces to errors.
I think they probably do need to be done either in the same function call or an additional method call.
I was considering the possibility of switching over to using errtrace for my errors packages.
However, errtrace doesn't allow for creating new wrapping functions, only using its.
If you look in the link I sent, you will see a function WrapsSkip, where "skip" refers to skipping function calls in the stack trace. I don't see this kind of ability in errtrace other than to try to use its internal/pc package which does expose these abilities.
prashantv commentedon Feb 6, 2025
@gregwebs I merged a change to master which should allow other wrappers, see #108
It hasn't been released yet, but you can try that out by pointing to master.
gregwebs commentedon Feb 6, 2025
@prashantv thanks! That should do it.