Après de nombreuses années d'expérience avec php et js, j'ai l'habitude d'avoir une erreur de trace de pile et de regarder l'endroit où l'erreur s'est produite directement à partir du rapport d'erreur. Il y a quelques années, en reprenant Go, j'ai été quelque peu surpris que Go ait des règles différentes et vous devez deviner la trace de la pile sur une ligne comme `caractère invalide`. Et si cela s'est produit sur le prod et qu'on ne sait pas le reproduire, alors cela s'est transformé en toute une attraction.
Comme je suis sûr que personne n'a souffert de cela, j'ai fait un package qui peut le faire:

→
GitHubIl ne fait que:
- Ajoute une trace de pile aux erreurs.
- Affiche la trace de pile et les fragments source où cette erreur s'est produite (en présence de source, bien sûr).
Ajout d'une trace de pile
Il existe plusieurs façons de créer un bogue avec une trace de pile:
Lorsque l'erreur est reconditionnée, la trace de pile restera la même et ne sera pas remplacée, ceci est pratique si on ne sait pas si l'erreur a déjà une trace de pile ou non.
Le code peut ressembler à ceci:
func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data)
Affichage de trace de pile
Après l'erreur jusqu'à 100500
if err != nil { return err }
retourne dans votre pays natal dans
main()
(ou là où il est traité), vous voudrez probablement l'afficher ou le promettre.
Il y a plusieurs options pour cela: tous fonctionnent comme Print (imprime du texte) ou Sprint (renvoie du texte):
1) Afficher le texte d'erreur et la trace de la pile:
tracerr.Print(err)
2) Affichez le texte d'erreur, la trace de pile et le fragment source (6 lignes par défaut):
tracerr.PrintSource(err)
3) Le même, mais en couleur, généralement plus informatif:
tracerr.PrintSourceColor(err)
4) Vous pouvez passer en paramètre le nombre de lignes de code à afficher:
tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9)
5) Ou passez 2 paramètres optionnels, combien avant et combien après la ligne avec l'erreur à afficher:
tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2)
Des questions
J'ai déjà reçu des commentaires, je me permets donc de répondre à l'avance à certaines des questions qui ont déjà été posées.
Q: Est-ce approprié uniquement pour le débogage? Il y a un débogueur.R: Cela convient non seulement pour le débogage, il est possible de consigner les erreurs avec des informations sur la trace de la pile, et même avec des fragments de codes source, sur le prod, comme dans mon expérience, cela simplifiera grandement l'analyse de ces erreurs.
Q: Il y a un super paquet / erreurs, pourquoi ne pas l'utiliser?R: Oui, je l'ai moi-même utilisé complètement et je suis content, mais cela ne me convenait pas pour ces raisons:
1) Il n'y a pas de moyen simple d'afficher immédiatement une trace de pile avec la source.
2) Lorsque l'erreur est reconditionnée (par exemple, un niveau plus haut), la trace de pile est remplacée par des traces moins informatives.
3) Il est impératif d'envoyer du texte d'erreur supplémentaire à chaque tour, ce qui me semble être une surcharge lors de l'écriture / lecture du code.
Q: Dans Go, les erreurs ne sont pas des exceptions et vous ne pouvez pas le faire du tout.R: Je suis d'accord, les erreurs dans Go ne font pas exception. Si vous préférez traiter des milliers
if err != nil { return err }
une autre manière - c'est votre choix, bien sûr. Vous ne pouvez encapsuler que les erreurs que vous gérez comme exceptions.
Q: Stectrace ajoute une surcharge aux performances.R: Oui, ajoute-t-il, mais cela n'est pertinent que pour les endroits où des erreurs sont créées en grande quantité, il ne suffit pas d'y ajouter une trace de pile si elle est critique (je suis sûr que dans la plupart des cas, cette surcharge est négligeable).
En général, j'espère que ce forfait vous facilitera la vie un peu plus, je serai heureux de tout commentaire, merci.