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
Having all fields for the error builder settable via context.Context would make it easy to make sure that any error further down in the chain has e.g., the domain set.
Motivation
For us the use case is that we have different areas of the code where it would be nice to always be able to ensure all errors have a domain or tags set.
Rather than enforcing everyone to remember to add In -- which sometimes might even be possible to figure out as you don't know what the call-chain is -- you set the In via the context and then as long as you do WithContext it will get set automatically.
Interface
In terms of interface I'm not sure what would be the best to avoid confusion. I can think of a few different ways
Prefixing with With.
Prefixing with WithContext.
Prefixing with Context.
Setting a default OopsErrorBuilder in the context.
(1) would have functions like WithIn. It has the advantage of being similar to other APIs when using context but doesn't play very nicely with the already existing function With (WithWith?).
(2) would have functions like WithContextIn. It is similar to the above but still sounds weird (WithContextWith?) and is maybe unnecessarily verbose without much clarity.
(3) would have functions like ContextIn or ContextTags which while not fully in line with what you would expect in therms of API doesn't collide with other names used and is also fairly clear what it would do.
(4) would need only two functions WithBuilder which sets a default builder in the context that can then be retrieved with FromContext(ctx).
Example
As an example of how it could look.
First of all, you add what you want to the context, using:
ctx := oops.WithBuilder(ctx, oops.In("domain"))
Then somewhere further down the call chain you then do
return oops.FromContext(ctx).Wrap(err)
The text was updated successfully, but these errors were encountered:
Having all fields for the error builder settable via
context.Context
would make it easy to make sure that any error further down in the chain has e.g., thedomain
set.Motivation
For us the use case is that we have different areas of the code where it would be nice to always be able to ensure all errors have a domain or tags set.
Rather than enforcing everyone to remember to add
In
-- which sometimes might even be possible to figure out as you don't know what the call-chain is -- you set theIn
via the context and then as long as you doWithContext
it will get set automatically.Interface
In terms of interface I'm not sure what would be the best to avoid confusion. I can think of a few different ways
With
.WithContext
.Context
.OopsErrorBuilder
in the context.(1) would have functions like
WithIn
. It has the advantage of being similar to other APIs when usingcontext
but doesn't play very nicely with the already existing functionWith
(WithWith
?).(2) would have functions like
WithContextIn
. It is similar to the above but still sounds weird (WithContextWith
?) and is maybe unnecessarily verbose without much clarity.(3) would have functions like
ContextIn
orContextTags
which while not fully in line with what you would expect in therms of API doesn't collide with other names used and is also fairly clear what it would do.(4) would need only two functions
WithBuilder
which sets a default builder in the context that can then be retrieved withFromContext(ctx)
.Example
As an example of how it could look.
First of all, you add what you want to the context, using:
Then somewhere further down the call chain you then do
The text was updated successfully, but these errors were encountered: