Context is for cancelation

This is a creation in Article, where the information may have evolved or changed.

In my previous post I suggested that the best part of the compile time coupling between the logger and the Loggee was Passing in a logger interface if constructing each major type in your program. The suggestion have been floated several times that logging are context specific, so maybe a logger can be passed around via A context.Context . I think this suggestion was flawed ( context.Value as is the most uses of, but that's another story). This post explains why.

Context. Value () is goroutine thread Local storage

Using context. Context to pass a logger-a function is a poor design pattern. in effect context. Context is being used as a conduit to arbitrarily extend the API of any method that takes a context. Context value. it ' s like Python ' s  **kwargs , or whatever the name was for That ruby Patt Ern of always passing a hash. using context. Context In this is the avoids an API breaks by smuggling data in the unstructured bag of values attached to the context . It ' s thread local storage in a cheap suit.

It's not just that values is boxed into a interface{} inside that context.WithValue I object to. The far further serious concern is there are no schema to this data, so there is the no-method for a, then takes a context to E Nsure that it contains the specific key required to complete the operation. context.Valuereturns nil if the key isn't found, which means any code doing the naïve

LOG: = CTX. Value ("Logger"). (log. Logger) log. Warn ("Something you ll ignore later")

Would blow up if the "logger" key was not present.

Sure, you can check that the assertion succeeded, but I feel pretty confident so if this pattern were to become popular Then people would eschew the the the both arg form of type assertion and just expect that the key always returned a valid logger. This would being especially true as logging in error paths are rarely tested, so you'll hit this if you need it the most.

In my opinion passing loggers inside would is the worst solution to the problem of context.Context decoupling loggers from implement Ations. We ' d has gone from a explicit compile time dependency to a implicit run time dependency, one that could not being enforced by the compiler.

To quote @freeformz

Loggers should is injected into dependencies. Full stop.

It ' s verbose, but it's the only-to-achieve decoupled design.

Related Posts:

1. Logger anti pattern
2. Building Go 1.5 on the Raspberry Pi
3. Don ' t just check errors, handle them gracefully
4. should methods be declared on T or *t