Hogyan kezeli a Go a hibákat értékekként?

Question

Accepted Answer

A Go-nak **nincsenek kivételei** a szokásos hibák számára. Helyette a hibák **értékek**, amelyeket függvények adnak vissza (általában az utolsó visszatérési érték), és a hívók **explicit módon ellenőrzik** azokat. Ez a hibakezelést **láthatóvá, szándékosá és lehetlenné teszi a hallgatólagos figyelmen kívül hagyás** — a Go lényegi filozófiája.

## Miért fontos ez

```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 `if err != nil { ... }` ellenőrzés folyamatosan megjelenik a Go-ban — minden sikertelen művelet után egy explicit hibavizsgálat követi. Ez a terjedelmesség szándékos: a hibák mindig láthatóak és a hívási helyen kezelve vannak.

## Hibák létrehozása

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

## Hibák csomagolása és vizsgálata

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

A csomagolás (`%w`) kontextust ad hozzá, amint a hibák felfelé terjednek, míg az `errors.Is`/`errors.As` lehetővé teszi adott alapul szolgáló hibák ellenőrzését vagy kinyerését — a hibás láncok kezelésének modern módja.

## Egyéni hibanevek

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

A Go hibákat értékekként kezelő megközelítése az egyik legsajátosabb és legtöbb vitatott jellegzetessége, alapvetően eltérő az ausnahmealapú nyelvektől.

Az olyan értékek visszatérésével, amelyeket a hívók explicit módon ellenőrizniük kell (`if err != nil`), a Go a hibakezelést **láthatóvá, helyi és lehetlenné teszi a véletlen figyelmen kívül hagyás** — pontosan látja, hogy az egyes hibák hol kezelve vannak, javítva a megbízhatóságot a terjedelmesség költsége árán.

Ennek a filozófiának, az `(result, error)` mintának, a hibacsomagolásnak (`%w`) az `errors.Is`/`errors.As` segítségével történő kontextus hozzáadáshoz és láncok vizsgálatához, az egyéni hibatípusokhoz és a hibák (normál, helyreállítható) és a panic (kivételes, programozó hibák) közötti különbség megértése abszolút lényeges — áthatja minden Go programot és alapvető mentális váltást jelent a kivétel alapú nyelvekből érkező fejlesztők számára.

Ez is egyike a leggyakoribb Go interjúkérdéseknek.