Aumentando o conteúdo do erro Go - github.com/ztrue/tracerr

Depois de muitos anos de experiência trabalhando com php e js, estou acostumado a rastrear a pilha nos erros e a olhar para o local em que o erro ocorreu diretamente no relatório de erros. Reseeding on Go há alguns anos atrás, fiquei um pouco surpreso que o Go tenha regras diferentes e você precise adivinhar o rastreamento da pilha em alguma linha como "caractere inválido". E se aconteceu no prod e não se sabe como reproduzi-lo, isso se transformou em uma atração inteira.

Como tenho certeza de que ninguém sofreu com isso, fiz um pacote que pode fazer isso:



→ GitHub

Tudo o que ele faz é:

1. Adiciona rastreamento de pilha a erros.
2. Exibe o rastreamento da pilha e os fragmentos de origem em que esse erro ocorreu (na presença da origem, é claro).

Incluindo rastreamento de pilha

Existem várias maneiras de criar um bug com um rastreamento de pilha:

//   err := tracerr.New("some error") //   Errorf,    ,   fmt.Errorf err := tracerr.Errorf("some error %d", num) //    ,    err = tracerr.Wrap(err) 

Quando o erro é reorganizado, o rastreamento da pilha permanece o mesmo e não será substituído, isso é conveniente se não for conhecido se o erro já possui um rastreamento da pilha ou não.

O código pode ser algo como isto:

 func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data) //  err = nil,   nil return tracerr.Wrap(err) } 

Exibição de rastreamento de pilha

Após o erro de 100500, if err != nil { return err } retorna à sua pátria em main() (ou onde é processado), provavelmente você deseja exibi-lo ou comprometê-lo.
Existem várias opções para isso: todas funcionam como Imprimir (imprime texto) ou Sprint (retorna texto):

1) Exibir texto de erro e rastreamento de pilha:

 tracerr.Print(err) 

2) Exiba o texto do erro, o rastreamento da pilha e o fragmento de origem (6 linhas por padrão):

 tracerr.PrintSource(err) 

3) O mesmo, mas em cores, geralmente mais informativo:

 tracerr.PrintSourceColor(err) 

4) Você pode passar como parâmetro quantas linhas de código exibir:

 tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9) 

5) Ou passe 2 parâmetros opcionais, quantos antes e quanto após a linha com o erro a ser exibido:

 tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2) 

Perguntas

Já recebi algum feedback, por isso me permito responder com antecedência algumas das perguntas que já foram feitas.

P: Isso é adequado apenas para depuração? Existe um depurador.
R: Isso é adequado não apenas para depuração, é possível registrar erros com informações sobre o rastreamento de pilha, e mesmo com fragmentos de códigos-fonte no produto, como na minha experiência, isso simplificará bastante a análise desses erros.

P: Existe um super pacote pkg / errors, por que não usá-lo?
R: Sim, eu mesmo o usei completamente e estou feliz, mas não me agradou por estes motivos:
1) Não há uma maneira fácil de exibir um rastreamento de pilha imediatamente com a fonte.
2) Quando o erro é repetido (por exemplo, um nível acima), o rastreamento da pilha é sobrescrito pelos menos informativos.
3) É imperativo enviar texto de erro adicional a cada turno, o que me parece um pouco sobrecarregado ao escrever / ler código.

P: No Go, erros não são exceções e você não pode fazer isso.
A: Eu concordo, os erros no Go não são excepção. Se você preferir processar milhares, if err != nil { return err } alguma outra maneira - essa é sua escolha, é claro. Você só pode agrupar os erros que você manipula como exceções.

P: O Stectrace adiciona uma sobrecarga ao desempenho.
R: Sim, acrescenta, mas isso é relevante apenas para locais onde erros são criados em grandes quantidades, apenas não adicione um rastreamento de pilha se for crítico (tenho certeza de que na maioria dos casos essa sobrecarga é insignificante).

Em geral, espero que este pacote torne sua vida mais fácil, ficarei feliz em receber qualquer feedback, obrigado.