Jak Go obsługuje błędy jako wartości?

Question

Accepted Answer

Go **nie ma wyjątków** dla błędów zwykłych. Zamiast tego błędy to **wartości** zwracane z funkcji (zazwyczaj jako ostatnia wartość zwrotna), a wywołujący **jawnie je sprawdzają**. To sprawia, że obsługa błędów jest widoczna, świadoma i niemożliwa do cichego ignorowania — to definiująca filozofia Go.

## Typ error i wzorzec bazowy

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

Sprawdzenie `if err != nil { ... }` pojawia się stale w Go — każda operacja, która może się nie powieść, jest następowana wyraźnym sprawdzeniem błędu. Ta gadatliwość jest celowa: błędy są zawsze widoczne i obsługiwane w miejscu wywołania.

## Tworzenie błędów

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

## Owijanie i inspektowanie błędów

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

Owijanie (`%w`) dodaje kontekst w miarę propagacji błędów w górę, podczas gdy `errors.Is`/`errors.As` pozwalają sprawdzić lub wyodrębnić konkretne podstawowe błędy — nowoczesny sposób obsługi łańcuchów błędów.

## Niestandardowe typy błędów

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

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

## Dlaczego to ważne

Podejście Go do błędów jako wartości jest jedną z jego najbardziej definiujących i dyskutowanych cech, fundamentalnie różniące się od języków opartych na wyjątkach.

Przez zwracanie błędów jako wartości, które wywołujący muszą jawnie sprawdzić (`if err != nil`), Go sprawia, że obsługa błędów jest **widoczna, lokalna i niemożliwa do przypadkowego ignorowania** — dokładnie widzisz, gdzie każdy błąd jest obsługiwany, co poprawia niezawodność kosztem gadatliwości.

Zrozumienie tej filozofii, wzorca `(result, error)`, owijania błędów (`%w`) za pomocą `errors.Is`/`errors.As` w celu dodania kontekstu i inspektowania łańcuchów, niestandardowych typów błędów oraz rozróżnienia między błędami (normalne, możliwe do odzyskania) a panic (wyjątkowe, błędy programisty) jest absolutnie konieczne — przenika każdy program Go i reprezentuje fundamentalną zmianę myślenia dla programistów przychodzących z języków opartych na wyjątkach.

To również jeden z najczęstszych tematów w rozmowach kwalifikacyjnych do Go.