Como o Go trata erros como valores?

Question

IT Interview Practice · Accepted Answer

Go **não possui exceções** para erros ordinários. Em vez disso, erros são **valores** retornados por funções (tipicamente como o último valor de retorno), e os chamadores **verificam explicitamente** esses valores. Isso torna o tratamento de erros visível, deliberado e impossível de ignorar silenciosamente — uma filosofia definidora do Go.

## O tipo error e o padrão central

```go
// `error` is a built-in interface: anything with an Error() string method
type error interface {
    Error() string
}

// functions return (result, error) — error is nil on success
func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("division by zero")   // create an error
    }
    return a / b, nil    // nil = no error
}

// the ubiquitous calling pattern
result, err := divide(10, 0)
if err != nil {              // CHECK the error explicitly
    fmt.Println("error:", err)
    return
}
fmt.Println(result)
```

A verificação `if err != nil { ... }` aparece constantemente em Go — toda operação que pode falhar é seguida por uma verificação explícita de erro. Essa verbosidade é deliberada: erros são sempre visíveis e tratados no local da chamada.

## Criando erros

```go
errors.New("something failed")                       // simple error
fmt.Errorf("failed to process %s: %w", name, err)    // formatted, with WRAPPING (%w)
```

## Envolvendo e inspecionando erros

```go
// %w WRAPS an underlying error, preserving the chain
if err != nil {
    return fmt.Errorf("reading config: %w", err)   // adds context, keeps original
}

// unwrap and inspect with errors.Is / errors.As
if errors.Is(err, os.ErrNotExist) { ... }          // check for a specific error
var pathErr *os.PathError
if errors.As(err, &pathErr) { ... }                 // extract a specific error type
```

Envolver (`%w`) adiciona contexto conforme os erros propagam para cima, enquanto `errors.Is`/`errors.As` permitem verificar ou extrair erros específicos subjacentes — a forma moderna de lidar com cadeias de erros.

## Tipos de erro customizados

```go
type ValidationError struct {
    Field string
}
func (e *ValidationError) Error() string {           // implement the error interface
    return "invalid field: " + e.Field
}
return &ValidationError{Field: "email"}
```

## errors vs panic

```text
error (values) → EXPECTED, recoverable conditions (file missing, bad input) — the norm
panic          → UNEXPECTED, programmer errors / unrecoverable (nil deref, out of bounds)
→ Use errors for normal failure handling; reserve panic for truly exceptional cases.
```

## Por que isso importa

A abordagem de Go com erro como valor é uma de suas características mais definidoras e debatidas, fundamentalmente diferente de linguagens baseadas em exceções.

Ao retornar erros como valores que os chamadores devem verificar explicitamente (`if err != nil`), Go torna o tratamento de erros **visível, local e impossível de ignorar acidentalmente** — você vê exatamente onde cada erro é tratado, melhorando a confiabilidade ao custo da verbosidade.

Entender essa filosofia, o padrão `(resultado, erro)`, envolvimento de erros (`%w`) com `errors.Is`/`errors.As` para adicionar contexto e inspecionar cadeias, tipos de erro customizados e a distinção entre erros (normais, recuperáveis) e panic (excecionais, erros do programador) é absolutamente essencial — permeia cada programa Go e representa uma mudança mental fundamental para desenvolvedores vindos de linguagens baseadas em exceções.

Também está entre os tópicos de entrevista do Go mais comuns.

O tipo error e o padrão central

Criando erros

Envolvendo e inspecionando erros

Tipos de erro customizados

errors vs panic

Por que isso importa

Perguntas relacionadas