Go غلطیوں کو اقدار کے طور پر کیسے سنبھالتا ہے؟

Question

Accepted Answer

Go میں **کوئی exceptions نہیں ہیں** عام غلطیوں کے لیے۔ اس کے بجائے، غلطیاں **اقدار** ہیں جو functions سے return ہوتی ہیں (عام طور پر آخری return value کے طور پر)، اور callers انہیں **صراحت سے check** کرتے ہیں۔ یہ error handling کو نمایاں، ارادی، اور خاموشی سے نظر انداز کرنا ناممکن بناتا ہے — یہ Go کا ایک بنیادی فلسفہ ہے۔

## error type اور بنیادی pattern

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

`if err != nil { ... }` check Go میں مسلسل نظر آتا ہے — ہر fallible operation کے بعد ایک صراحت سے error check آتا ہے۔ یہ verbosity ارادی ہے: غلطیاں ہمیشہ نمایاں ہوتی ہیں اور call site پر سنبھالی جاتی ہیں۔

## غلطیاں بنانا

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

## Wrapping اور غلطیوں کا معائنہ کرنا

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

Wrapping (`%w`) سیاق و سباق شامل کرتا ہے جیسے errors اوپر کی طرف پھیلتی ہیں، جبکہ `errors.Is`/`errors.As` آپ کو مخصوص underlying errors کو check کرنے یا نکالنے دیتے ہیں — error chains سے نمٹنے کا جدید طریقہ۔

## Custom error types

```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 بمقابلہ 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.
```

## یہ اہم کیوں ہے

Go کا error-as-value انجام نقطہ نظر اس کے سب سے بنیادی اور متنازع خصوصیات میں سے ایک ہے، جو exception-based languages سے بنیادی طور پر مختلف ہے۔

غلطیوں کو اقدار کے طور پر return کر کے جو callers کو صراحت سے check کرنا لازمی ہے (`if err != nil`)، Go error handling کو **نمایاں، مقامی، اور غلطی سے نظر انداز کرنا ناممکن** بناتا ہے — آپ بالکل دیکھتے ہیں کہ ہر غلطی کہاں سنبھالی جاتی ہے، reliability میں اضافہ کرتے ہوئے verbosity کی قیمت پر۔

اس فلسفے کو سمجھنا، `(result, error)` pattern، error wrapping (`%w`) `errors.Is`/`errors.As` کے ساتھ سیاق و سباق شامل کرنے اور chains کا معائنہ کرنے کے لیے، custom error types، اور errors (عام، قابل تعمیر) اور panic (غیر معمولی، programmer کی غلطیوں) کے درمیان امتیاز بالکل ضروری ہے — یہ ہر Go program میں پھیلا ہوا ہے اور exception-based languages سے آنے والے developers کے لیے ایک بنیادی ذہنی تبدیلی کی نمائندگی کرتا ہے۔

یہ Go انٹرویو کے سب سے عام موضوعات میں سے ایک بھی ہے۔