DEV Community

Cover image for Go Context — TODO() vs Background() No more confusing!
zakaria chahboun
zakaria chahboun

Posted on

Go Context — TODO() vs Background() No more confusing!

In Go, the context package helps manage request-scoped values, cancellation signals, and deadlines.
Two common ways to start a context are context.TODO() and context.Background().
Though they behave similarly, they serve different purposes.

context.Background()

context.Background() is the default when you don’t need any special handling (like cancellation or deadlines).
It's often used in main, init, or when initializing operations that don't need a more specific context.

Example:

 func main() {
     ctx := context.Background()
     server := http.Server{Addr: ":8080", BaseContext: func(net.Listener) context.Context {
         return ctx
     }}
     log.Fatal(server.ListenAndServe())
 }
Enter fullscreen mode Exit fullscreen mode

In this example, context.Background() is used to establish a base context for the HTTP server.

context.TODO()

context.TODO() is a placeholder context. Use it when you're unsure of what context to provide or when planning to refactor later.

Example:

 func processOrder() {
     ctx := context.TODO() // Placeholder, decision on context pending
     err := db.SaveOrder(ctx, orderData)
     if err != nil {
         log.Println("Failed to save order:", err)
     }
 }
Enter fullscreen mode Exit fullscreen mode

Here, context.TODO() is temporarily used for a database operation until a more specific context is defined.

Key Differences

Both functions return an empty context, but they express different intentions:

  • context.Background(): Used when you're confident no special context features are needed.
  • context.TODO(): A temporary placeholder context, signaling future changes.

Conclusion

When to Use context.Background():

  • When initializing core services like HTTP servers or database connections.
  • When there's no need for cancellation, deadlines, or values.

When to Use context.TODO():

  • When refactoring, and you haven’t decided on the context yet.
  • When implementing early-stage code that requires future improvements.

Top comments (1)

Collapse
 
bashery profile image
bashery

Short and useful, thanks.