Si e përballë Go gabimet si vlera?

Question

IT Interview Practice · Accepted Answer

Go **nuk ka përjashtime** për gabimet e zakonshme. Në vend të kësaj, gabimet janë **vlera** të kthyera nga funksionet (zakonisht si vlera e fundit e kthimit), dhe thirrësit **kontrollojnë në mënyrë eksplicite** ato. Kjo e bën trajtimin e gabimeve të dukshëm, të qëllimshëm, dhe të pamundur për t'u inoruar në heshtje — një filozofi përcaktuese e Go.

## Lloji error dhe modeli 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)
```

Kontrolli `if err != nil { ... }` shfaqet në mënyrë konstante në Go — çdo operacion që mund të dështojë përcillet nga një kontroll eksplicite i gabimit. Kjo zgjatje është e qëllimshme: gabimet janë gjithmonë të dukshme dhe trajtohen në vendin e thirrjes.

## Krijimi i gabimeve

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

## Mbështjellja dhe inspektimi i gabimeve

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

Mbështjellja (`%w`) shton kontekst ndërsa gabimet përhapen lart, ndërsa `errors.Is`/`errors.As` ju lejojnë të kontrolloni për ose të nxirrni gabime specifike themelore — mënyra moderne për të trajtuar zinxhirët e gabimeve.

## Llojet e gabimeve të personalizuara

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

## Përse ka rëndësi

Qasja e Go ndaj gabimit-si-vlere është një nga karakteristikat e tij më përcaktuese dhe të debatuara, thelbësisht e ndryshme nga gjuhët e bazuara në përjashtime.

Me kthimin e gabimeve si vlera që thirrësit duhet të kontrollojnë në mënyrë eksplicite (`if err != nil`), Go e bën trajtimin e gabimeve **të dukshëm, lokal, dhe të pamundur për t'u inoruar aksidentalisht** — shihni saktësisht ku trajtohet çdo gabim, duke përmirësuar besueshmërinë me koston e zgjatjes.

Përkuptimi i kësaj filozofie, modeli `(result, error)`, mbështjellja e gabimeve (`%w`) me `errors.Is`/`errors.As` për shtimin e kontekstit dhe inspektimin e zinxhirëve, llojet e gabimeve të personalizuara, dhe dallimi midis gabimeve (normale, të rimarrjeshme) dhe panic (përjashtim, gabime të programuesit) është absolutisht thelbësor — ai përshkon çdo program Go dhe përfaqëson një zhvendosje mendore themelore për zhvilluesit që vijnë nga gjuhët e bazuara në përjashtime.

Eshtë gjithashtu midis temave më të zakonshme të intervistës në Go.

Lloji error dhe modeli bazë

Krijimi i gabimeve

Mbështjellja dhe inspektimi i gabimeve

Llojet e gabimeve të personalizuara

errors vs panic

Përse ka rëndësi

Pyetje të ngjashme