Come Go gestisce gli errori come valori?

Question

Accepted Answer

Go **non ha eccezioni** per gli errori ordinari. Invece, gli errori sono **valori** restituiti dalle funzioni (tipicamente come ultimo valore di ritorno), e i chiamanti li **controllano esplicitamente**. Questo rende la gestione degli errori visibile, deliberata e impossibile da ignorare silenziosamente — una filosofia distintiva di Go.

## Il tipo error e il pattern fondamentale

```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)
```

Il controllo `if err != nil { ... }` appare costantemente in Go — ogni operazione fallibile è seguita da un controllo esplicito dell'errore. Questa verbosità è deliberata: gli errori sono sempre visibili e gestiti nel sito di chiamata.

## Creare errori

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

## Wrapping e ispezione degli errori

```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
```

Il wrapping (`%w`) aggiunge contesto mentre gli errori si propagano verso l'alto, mentre `errors.Is`/`errors.As` ti permettono di controllare o estrarre errori sottostanti specifici — il modo moderno di gestire catene di errori.

## Tipi di errore personalizzati

```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.
```

## Perché è importante

L'approccio di Go dell'errore come valore è una delle sue caratteristiche più distintive e dibattute, fondamentalmente diversa dai linguaggi basati su eccezioni.

Restituendo gli errori come valori che i chiamanti devono controllare esplicitamente (`if err != nil`), Go rende la gestione degli errori **visibile, locale e impossibile da ignorare accidentalmente** — vedi esattamente dove ogni errore viene gestito, migliorando l'affidabilità al costo della verbosità.

Comprendere questa filosofia, il pattern `(result, error)`, il wrapping degli errori (`%w`) con `errors.Is`/`errors.As` per aggiungere contesto e ispezionare le catene, i tipi di errore personalizzati, e la distinzione tra errori (normali, recuperabili) e panic (eccezionali, errori del programmatore) è assolutamente essenziale — permea ogni programma Go e rappresenta un cambio mentale fondamentale per gli sviluppatori provenienti da linguaggi basati su eccezioni.

È anche tra i topic più comuni nei colloqui Go.