Skip to content

Instantly share code, notes, and snippets.

@tj

tj/index.md Secret

Last active April 3, 2019 07:58
Show Gist options
  • Save tj/638adb053f802e6c19686bd2fee443b7 to your computer and use it in GitHub Desktop.
Save tj/638adb053f802e6c19686bd2fee443b7 to your computer and use it in GitHub Desktop.

The approach presented here does not provide any standard to programmatically extract the information that is to be displayed in the messages. It seems, though, there is no need for this.

As a structured logging & tracing advocate this could not be more untrue in my experience — structured logging requires this contextual data to be accessible. Error messages must not be high-cardinality with dynamic information, such as "copy: foo.json to bar.json", as it is difficult to index and query against.

Ideally we have access to all contextual information as fields, and the primary "message" is either a single or sequence of low cardinality strings. The current printing interface does not accomplish this at all, I think it's awkward to have the error format itself, if we standardize some kind of error "fields", then a top-level function can perform the formatting, or in the case of structured logging, can simply produce a transmission or storage format such as Parquet or JSON.

@ainar-g
Copy link

ainar-g commented Apr 3, 2019

Not sure if that's what you want, but you can already create a good-enough json error message.

See https://play.golang.org/p/eNLfIZpqc4B.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment