Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Proposal] Set domain, tags etc. via the context

Aperta
  • Qualcosa non va?
#37 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
go
Ambito
backend

Direzione di ricerca

Non vengono indicati file di implementazione né test. Inizia leggendo le API esistenti di In, With, WithContext e del generatore di errori, quindi confronta le interfacce di contesto proposte e le loro interazioni. Il lavoro è completato quando un’interfaccia decisa è implementata, in modo che i campi trasportati dal contesto raggiungano gli errori più avanti nella catena di chiamate, con una copertura per l’esempio documentato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

  1. Prefixing with With.
  2. Prefixing with WithContext.
  3. Prefixing with Context.
  4. 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)
Lingua principale
Go
Stelle
996
Fork
45
Merge medio
1m
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di samber/oops

Tutte le issue di samber/oops

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.