Cum gestionează Go erorile ca valori?

Question

IT Interview Practice · Accepted Answer

Go **nu are excepții** pentru erorile obișnuite. În schimb, erorile sunt **valori** returnate din funcții (de obicei ca ultima valoare de retur), iar apelatorii **verifică explicit** dacă au apărut erori. Acest lucru face gestionarea erorilor vizibilă, deliberată și imposibil de ignorat în tacere — o filozofie definitoare a Go.

## Tipul error și modelul de bază

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

Verificarea `if err != nil { ... }` apare constant în Go — fiecare operație care poate eșua este urmată de o verificare explicită a erorii. Această verbozitate este deliberată: erorile sunt întotdeauna vizibile și gestionate la locul apelului.

## Crearea erorilor

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

## Înfășurarea și inspectarea erorilor

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

Înfășurarea (`%w`) adaugă context pe măsură ce erorile se propagă în sus, în timp ce `errors.Is`/`errors.As` vă permit să verificați sau să extrageți erori specifice subiacente — modul modern de a gestiona lanțurile de erori.

## Tipuri de erori personalizate

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

## De ce este important

Abordarea error-ca-valoare a lui Go este una dintre caracteristicile sale cele mai definitorii și dezbătute, fundamental diferită de limbajele bazate pe excepții.

Prin returnarea erorilor ca valori pe care apelatorii trebuie să le verifice explicit (`if err != nil`), Go face gestionarea erorilor **vizibilă, locală și imposibil de ignorat accidental** — vedeți exact unde fiecare eroare este tratată, îmbunătățind fiabilitatea cu costul verbozității.

Înțelegerea acestei filozofii, modelul `(result, error)`, înfășurarea erorilor (`%w`) cu `errors.Is`/`errors.As` pentru adăugarea contextului și inspectarea lanțurilor, tipurile de erori personalizate și distincția între erori (normale, recuperabile) și panic (excepționale, erori de programator) este absolut esențială — penetrează fiecare program Go și reprezintă o schimbare mentală esențială pentru dezvoltatorii care vin din limbaje bazate pe excepții.

Este, de asemenea, printre cele mai frecvente subiecte din interviurile pentru Go.

Tipul error și modelul de bază

Crearea erorilor

Înfășurarea și inspectarea erorilor

Tipuri de erori personalizate

errors vs panic

De ce este important

Întrebări conexe