Error Handling

This chapter is about dealing with errors and panics in a concurrent program. First, we will look at how error handling can be incorporated into concurrent programs, including how to pass errors between goroutines so that you can handle or report them. Then we will talk about panics.

There are no hard and fast rules about dealing with errors and panics, but I hope some of the guidelines described in this chapter will help you write more robust code. The first guideline is this: never ignore errors. The second guideline tells you when to return an error and when to panic: the audience for errors is the users of the program; the audience for panics is the developers of the program.

This chapter contains the following sections:

• Error handling
• Panics

At the end of this chapter, you will have seen several approaches to error handling in concurrent programs.

Error handling

Error handling in Go has been a polarizing issue. Frustrated with the repetitive error-handling boilerplate, many Go users in the community (including me) suggested improved error-handling mechanisms. Most of these proposals were actually error-passing improvements because, to be honest, errors are rarely handled. Rather, they are passed to the caller, sometimes wrapped with some contextual information.

A good number of error-handling proposals suggested different variations on throw-catch, while many others were simply what is called syntactic sugar for if err!=nil return err. Many of these proposals missed the point that the existing error reporting and handling conventions work nicely in a concurrent environment, such as the ability to pass errors via a channel: you can handle errors generated by one goroutine in another goroutine.

An important point I like to emphasize when working with Go programs is that most of the time, they can be analyzed by solely relying...

Panics

Panics are different from errors. A panic is either a programming error or a condition that cannot be reasonably remedied (such as running out of memory.) Because of this, a panic should be used to convey as much diagnostic information to the developer as possible.

Some errors can become panics depending on the context. For instance, a program may accept a template from the user and generate an error if the template parsing fails. However, if the parsing of a hardcoded template fails, then the program should panic. The first case is a user error, and the second case is a bug.

As a developer of concurrent programs, there are only three things you can do with an error: you either handle it (log it, choose another program flow, or ignore it by doing nothing), you pass it to the caller (sometimes with some additional contextual information), or you panic. When a panic happens in a concurrent program, the runtime ensures that all the nested function calls return, one by one...

Summary

Your programs must generate useful error messages that tell the users what went wrong and how they can fix it. Go gives the developer full control over how errors are generated and how they are passed around. In this chapter, we saw some methods to deal with errors generated concurrently.

Next, we will look at timers and tickers for scheduling events in the future.