Blog / Go Routines

Simpler error handling in goroutines

August 29, 2025

Join me later today at 3:00pm EDT (19:00 UTC), for more live coding. Subscribe on YouTube and hit the Notify me button so you don’t miss it!

Yesterday we looked at how to handle errors from multiple goroutines using an error channel. While functional, the approach is somewhat complicated, and easy to get wrong.

Enter errgroup. While not part of the standard library, it is maintained by the Go team, and is widely used in the Go ecosystem. It provides a simple way to manage a group of goroutines that may return errors.

Let’s first look at our example code rewritten to use errgroup, then we’ll discuss.

func doManyThings() error {
	var g errgroup.Group

	for i := range 100 {
		g.Go(func() error {
			return doSomething(i)
		})
	}

	return g.Wait()
}

Whoa!

How much shorter and simpler that is, compared to the previous version! From 26 lines down to 11, with no loss in functionality.

So let’s see what this new code is doing.

First, we define a new errgroup.Group object. The zero value of an errgroup.Group is ready to use, so we don’t need to do any special initialization.

Then we call g.Go() with a function literal for each of our 100 tasks. This is similar to how we used sync.WaitGroup, but instead of calling wg.Go()*, we call g.Go(). The function we pass to g.Go() must return an error, which errgroup will capture.

Finally, we call g.Wait(), which blocks until all goroutines have completed. If any of the goroutines returned a non-nil error, g.Wait() will return that error. If multiple goroutines returned errors, only the first one is returned.

*Historical note: errgroup’s Go() method predates, and inspired the addition of Go() to sync.WaitGroup in Go 1.25.

Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content

Aborting goroutines on error

I’m sorry for the delay in writing. Last week I was under the weather. Let’s pick up our discussion of goroutines and errors. Last time, I talked about errgroup, which makes it easy to run an arbitrary number of goroutines, and gather the first error (if any) that one returns. But what if that error renders the rest of the goroutines obsolete? A very common case is that any error means that the rest of the processing becomes moot.

Limiting goroutines

The errgroup package we’ve been looking at lately has one more trick up its sleeve: Limiting the number of running goroutines. Let’s imagine we’re building an HTTP handler that responds with a list of all customer orders. Doing so, requires making a number of calls to the ‘orders’ microservice. Some customers may have made hundreds or thousands of orders. We don’t want to look them all up simultaneously, so we’ll limit our client to 10 concurrent requests.

Goroutines and error channels

Join me tomorrow, August 29, at 3:00pm EDT (19:00 UTC), for more live coding. Subscribe on YouTube and hit the Notify me button so you don’t miss it! Last week we looked at how to handle errors from multiple goroutines using a mutex and a shared error variable. While this works for many common scenarios, it has some limitations. For example, it only captures the first error encountered and ignores any subsequent errors.

Get daily content like this in your inbox!

Subscribe