मुहावरेदार त्रुटि प्रबंधन

गो में त्रुटि प्रबंधन स्पष्ट है: कोई अपवाद नहीं, कोई प्रयास/पकड़ नहीं। प्रत्येक फ़ंक्शन जो विफल हो सकता है वह error को अपने अंतिम मान के रूप में लौटाता है, और कॉल करने वाला निर्णय लेता है। यह अध्याय मजबूत तरीके से त्रुटियों को उत्पन्न करने, प्रचारित करने और निरीक्षण करने के लिए मुहावरेदार पैटर्न एकत्र करता है।

सुनहरा नियम

data, err := os.ReadFile(path)
if err != nil {
    return fmt.Errorf("config %s: %w", path, err)
}

चार सिद्धांत:

1. error अंतिम रिटर्न है।
2. तुरंत जांचें if err != nil से।
3. प्रचार करने से पहले संदर्भ जोड़ें (fmt.Errorf + %w के साथ)।
4. कभी भी किसी त्रुटि को अनदेखा न करें: या तो इसे संभालें, इसे लॉग करें, या इसे वापस कर दें।

_ = file.Close() // EXPLICITLY ignored (you know what you're doing)

प्रहरी त्रुटियाँ

सेंटिनल त्रुटि एक निर्यातित वैश्विक वैरिएबल var ErrXxx = errors.New("...") है जिसकी तुलना कॉल करने वाला कर सकता है:

package store

var ErrNotFound = errors.New("not found")

func Get(key string) (string, error) {
    if !exists(key) {
        return "", ErrNotFound
    }
    // ...
}

कॉल करने वाला errors.Is (== नहीं) का उपयोग करता है, जो रैप चेन पर चलता है:

v, err := store.Get(k)
if errors.Is(err, store.ErrNotFound) {
    // handle 404
}

मानक उदाहरण: io.EOF, sql.ErrNoRows, os.ErrNotExist।

कस्टम टाइप की गई त्रुटियाँ

संरचित डेटा (HTTP कोड, अमान्य फ़ील्ड, आदि) ले जाने के लिए, एक प्रकार परिभाषित करें:

type ValidationError struct {
    Field string
    Msg   string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Msg)
}

कॉलर श्रृंखला के साथ सुरक्षित रूप से डाउनकास्ट करने के लिए errors.As का उपयोग करता है:

var ve *ValidationError
if errors.As(err, &ve) {
    fmt.Println("invalid field:", ve.Field)
}

errors.As Unwrap() श्रृंखला पर तब तक चलता है जब तक उसे पास किए गए पॉइंटर को निर्दिष्ट करने योग्य कोई त्रुटि नहीं मिल जाती।

%w के साथ रैपिंग

fmt.Errorf %w क्रिया के साथ एक त्रुटि उत्पन्न होती है जो मूल को लपेट देती है, इसे errors.Is/errors.As के लिए संरक्षित करती है:

if err := db.Query(); err != nil {
    return fmt.Errorf("load users: %w", err)
}

%w के बिना (%v या %s का उपयोग करके) आपको एक समृद्ध स्ट्रिंग मिलती है लेकिन श्रृंखला खो जाती है: कॉलर अब विशिष्ट त्रुटियों को नहीं पहचान सकता है।

%w के नियम:

• प्रति fmt.Errorf कॉल में केवल एक (मल्टी-रैप के लिए errors.Join की आवश्यकता होती है)।
• तर्क एक error होना चाहिए, एक स्ट्रिंग नहीं।
• संदर्भ जोड़ें, मूल संदेश की नकल न करें।

// bad: duplicates
return fmt.Errorf("error: %w", err) // "error: file not found"

// good: useful context
return fmt.Errorf("load config %s: %w", path, err)

एकाधिक त्रुटियों के लिए errors.Join

गो 1.20 के बाद से, errors.Join(errs...) कई त्रुटियों को एक में जोड़ता है जो उन सभी को errors.Is/As द्वारा पता लगाने योग्य रखता है:

var errs []error
for _, item := range items {
    if err := process(item); err != nil {
        errs = append(errs, fmt.Errorf("item %s: %w", item.ID, err))
    }
}
if len(errs) > 0 {
    return errors.Join(errs...)
}

panic का उपयोग कब करें

अपेक्षित त्रुटियों के लिए कभी नहीं. केवल तीन मामलों में:

1. अपरिवर्तनीय बग: एक ऐसे स्थान पर उल्लंघन किया गया जो "नहीं हो सकता" (panic("unreachable"))।
2. एक स्टैंडअलोन प्रोग्राम के init()/main() में असफल आरंभीकरण (महत्वपूर्ण कॉन्फ़िगरेशन गुम → तेजी से विफल)।
3. लाइब्रेरी एपीआई जो स्पष्ट रूप से इसका दस्तावेजीकरण करती है: उदाहरण के लिए, regexp.MustCompile (यदि पैटर्न अमान्य है तो घबराएं - स्वीकार्य है क्योंकि पैटर्न एक बिल्ड-टाइम स्थिरांक है)।

बाकी सब कुछ error है। प्रचार करने के लिए panic को शॉर्टकट के रूप में उपयोग न करें: यह संरचना को तोड़ देता है, defer Close() को छोड़ देता है, और कॉल करने वाले को अभिभूत कर देता है।

अभ्यास

func F(x int) {
  // ??? panic(...)
}