Go त्रुटियों को मान के रूप में कैसे संभालता है?

Question

Accepted Answer

Go के पास सामान्य त्रुटियों के लिए **कोई अपवाद नहीं** है। इसके बजाय, त्रुटियां फ़ंक्शन से लौटाए गए **मान** हैं (आमतौर पर अंतिम रिटर्न मान के रूप में), और कॉलर्स उन्हें **स्पष्ट रूप से जांचते** हैं। यह त्रुटि हैंडलिंग को **दृश्यमान, जानबूझकर, और चुपचाप अनदेखा करना असंभव** बनाता है — Go की परिभाषित दर्शन।

## यह क्यों महत्वपूर्ण है

```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 { ... }` जांच Go में लगातार दिखाई देती है — प्रत्येक विफल ऑपरेशन के बाद एक स्पष्ट त्रुटि जांच होती है। यह विस्तार जानबूझकर है: त्रुटियां हमेशा दृश्यमान होती हैं और कॉल साइट पर हैंडल की जाती हैं।

## त्रुटियां बनाना

```go
errors.New("something failed")                       // simple error
fmt.Errorf("failed to process %s: %w", name, err)    // formatted, with WRAPPING (%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
```

लपेटना (`%w`) जैसे ही त्रुटियां ऊपर की ओर फैलती हैं, संदर्भ जोड़ता है, जबकि `errors.Is`/`errors.As` आपको विशिष्ट अंतर्निहित त्रुटियों की जांच या निकालने देते हैं — त्रुटि श्रृंखलाओं को हैंडल करने का आधुनिक तरीका।

## कस्टम त्रुटि प्रकार

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

Go की त्रुटि-मान-के-रूप दृष्टिकोण इसकी सबसे परिभाषित और विवादास्पद विशेषताओं में से एक है, अपवाद-आधारित भाषाओं से मौलिक रूप से भिन्न है।

जब कॉलर्स को स्पष्ट रूप से जांचना चाहिए ऐसे मानों के रूप में त्रुटियां लौटाकर (`if err != nil`), Go त्रुटि हैंडलिंग को **दृश्यमान, स्थानीय, और आकस्मिक रूप से अनदेखा करना असंभव** बनाता है — आप बिल्कुल देखते हैं कि प्रत्येक त्रुटि कहां हैंडल की जाती है, विश्वसनीयता में सुधार करते हुए शब्दांश की कीमत पर।

इस दर्शन, `(result, error)` पैटर्न, त्रुटि लपेटना (`%w`) `errors.Is`/`errors.As` के साथ संदर्भ जोड़ने और श्रृंखलाओं का निरीक्षण करने, कस्टम त्रुटि प्रकार, और त्रुटियों (सामान्य, पुनर्प्राप्य) और panic (असाधारण, प्रोग्रामर त्रुटियां) के बीच अंतर को समझना बिल्कुल आवश्यक है — यह हर Go प्रोग्राम में व्यापक है और अपवाद-आधारित भाषाओं से आने वाले डेवलपर्स के लिए एक मौलिक मानसिक बदलाव का प्रतिनिधित्व करता है।

यह Go साक्षात्कार विषयों में भी सबसे आम है।