Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__Esta emissão agora tem um financiamento de 10,0779 TRB (281,17 USD @ $ 27,9 / TRB) anexado a ela .__
@themandalore
Estou interessado em trabalhar neste assunto, convide-me através do Gitcoin
meu plano de trabalho é fazer todas as mudanças
@developerfred , enviado. Você é nosso macaco espacial no que diz respeito a testar toda essa coisa de gitcoin, então me avise se precisar de alguma coisa
@themandalore Obrigado, perfeito!
Parece que ainda há algum fmt.Errorf em httpRetriever.go e logConfig.go (o pacote util)
@developerfred
@themandalore Vou verificar aqui, obrigado por me avisar.
@themandalore concluído.
Parece bom, deixe-me saber as próximas etapas em relação ao gitcoin
@themandalore Você pode me adicionar à recompensa, quando tento expressar interesse, recebo um erro. Eu relatei para a equipe e estou analisando o código Gitcoin para ver o porquê.
meu usuário gitcoin :
@developerfred , eu realmente não consigo fazer nada. Vou entrar em contato com eles, mas se demorar mais de um ou dois dias, basta voltar, fecharemos e consertaremos manualmente
@themandalore perfeito, estou falando com eles também.
Eles vão consertar agora, então o processo é só me aprovar e depois pagar.
@themandalore pronto, agora você precisa me aprovar no Gitcoin, para eu enviar o PR.
Reabrindo porque eu tinha outra coisa em mente.
Precisamos utilizar errors.Wrap
, errors.Wrapf
e também remover as palavras que gaguejam para melhorar as mensagens de log. Palavras como - can't, error, failed
devem ser removidas, pois serão repetidas na mensagem de log final.
Aqui estão alguns exemplos de mudanças necessárias:
errors.Errorf("file %s stat error: %v", historyPath, err)
changed to
errors.Wrapf(err,"stats for file: %v", historyPath)
alternative - but I am not a big fan of this one as error prone.
errors.Errors("stats for file: %v, err:%w", historyPath,err)
Observe a remoção da palavra de erro - não precisamos dela, pois isso é claro e a mensagem de impressão final irá incluí-la duas vezes.
Usar errors.Wrap
nos permite fazer a correspondência de erros no chamador e geralmente é mais estruturado:
veja: https://blog.golang.org/go1.13-errors , Mencionou o uso de% w, mas não sou um fã, pois é bastante sujeito a erros. - é fácil de usar% v e difícil de seguir em PRs, então prefiro usar o método de embrulho.
No chamador, podemos fazer algo como if err == ErrNotFound
(correspondência de erro por tipo) que é mais difícil sem usar o método wrap.
errors.Errorf("failed to read psr file @ %s: %v", historyPath, err)
changed to
errors.Wrap(err,"read psr file:%v", historyPath)
observe novamente a remoção da palavra failed
ela não é necessária. Também aqui não usamos Wrapf
, mas apenas Wrap
Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__Trabalho foi iniciado__.
Cada um desses usuários afirmou que pode concluir o trabalho em 266 anos a partir de agora.
Reveja os seus planos de ação abaixo:
1) developerfred foi aprovado para iniciar o trabalho.
Eu adoraria trabalhar nesta questão, meu plano de trabalho é fazer todas as substituições
2) janus candidatou-se para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Já trabalhei em projetos Go antes e também tenho boas habilidades de Linux para encontrar e combinar palavras. Eu levaria apenas algumas horas para concluir esta tarefa.
3) zyfrank se candidatou para iniciar o trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Estou familiarizado com go, gostaria de realizar esta tarefa
4) fé foi aplicada para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.
Eu seria capaz de substituir todos eles manualmente ou automaticamente.
Saiba mais na página Detalhes do problema do Gitcoin .
Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído
__O trabalho para 10.0779 TRB (283,87 USD @ $ 28,16 / TRB) foi enviado por ___: