Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
errcode
-
Error stack traces in Go with x/xerror
I believe the solution to this is to classify errors properly. Any "internal error" as in HTTP 500 Internal Error should be generating a stack trace. Most other expected errors (like your case) should not. I codified this practice in a library I created for Go called errcode [1] which is designed to attach error codes and other meta information where errors are generated.
[1] https://github.com/pingcap/errcode
logutil
-
Error stack traces in Go with x/xerror
> At boundaries between our code and calls out to external packages, make an effort to always wrap the result with xerrors.Errorf. This ensures that we always capture a stack trace at the most proximate location of an error being generated as possible
I've been doing something similar for a while using `errors.WithStack` from https://github.com/pkg/errors
The error can then be logged with https://github.com/rs/zerolog like this `log.Error().Stack().Err(err).Msg("")`
And using a console writer it's possible to get human readable output instead of the standard JSON, see https://github.com/mozey/logutil
What are some alternatives?
json-logs - A tool to pretty-print JSON logs, like those from zap or logrus.
backward-cpp - A beautiful stack trace pretty printer for C++
xtrace - A simple library to extract traces from golang's xerrors
errors - Go error library with error portability over the network
golangci-lint - Fast linters Runner for Go
errors - Simple error handling primitives
zerolog - Zero Allocation JSON Logger