क्या एक गो पैकेज कभी लॉग का उपयोग करना चाहिए। घातक और कब?

Question

मैंने अब तक log.Fatal का उपयोग टाला है, लेकिन मैंने हाल ही में इन प्रश्नों को सह-खोजा है; code-coverage और tests-using-log-fatal।

100 कोड कवरेज सवालों से टिप्पणी में से एक का कहना है: ...

मामलों log.Fatal के विशाल बहुमत में केवल मुख्य, या init कार्यों में इस्तेमाल किया जा किया जाना चाहिए (या शायद कुछ बातें करने के लिए होती उन लोगों से केवल सीधे बुलाया जाना) "

यह मुझे सोच जाना है, इसलिए मैं जाओ के साथ प्रदान की मानक पुस्तकालय कोड को देखने के लिए शुरू कर दिया। वहाँ उदाहरण के बहुत सारे जहां पुस्तकालय में परीक्षण कोड का उपयोग करता है कर रहे हैं log.Fatal जो ठीक लगता है। वहाँ हैं ,

// net/http/transport.go 
func (t *Transport) putIdleConn(pconn *persistConn) bool { 
    ... 
    for _, exist := range t.idleConn[key] { 
     if exist == pconn { 
      log.Fatalf("dup idle pconn %p in freelist", pconn) 
     } 
    } 
    ... 
} 

अपने सबसे अच्छा अभ्यास log.Fatal के उपयोग से बचने के लिए है, तो क्यों है यह मानक पुस्तकालयों में बिल्कुल भी इस्तेमाल किया, मैं अपेक्षा की होगी: इस तरह के net/http में के रूप में परीक्षण कोड, के बाहर कुछ उदाहरण हैं, नीचे दिखाया गया है बस एक त्रुटि वापस करें। यह लाइब्रेरी के उपयोगकर्ता को os.Exit कहने के लिए अनुचित लगता है और एप्लिकेशन को साफ-सफाई के लिए कोई मौका नहीं प्रदान करता है।

मैं निष्पक्ष हो सकता हूं, इसलिए मेरा प्रश्न बेहतर अभ्यास के रूप में log.Panic पर कॉल करना प्रतीत होता है जिसे पुनर्प्राप्त किया जा सकता है और मेरे सैद्धांतिक लंबे चलने वाले स्थिर अनुप्रयोग को राख से बढ़ने का मौका मिल सकता है।

तो लॉग के समय के बारे में गो के लिए सबसे अच्छा अभ्यास क्या होगा। घातक का उपयोग किया जाना चाहिए?

Answer 1

यह सिर्फ मुझे हो सकता है, लेकिन यहां मैं log.Fatal का उपयोग कैसे करता हूं। यूनिक्स सम्मेलनों के अनुसार, एक प्रक्रिया जो त्रुटि का सामना करती है, एक गैर-शून्य निकास कोड के साथ जितनी जल्दी हो सके विफल होनी चाहिए। यह मैं निम्नलिखित दिशा-निर्देशों के लिए नेतृत्व जब log.Fatal उपयोग करने के लिए ...

1. ... मेरी func init() में से किसी में एक त्रुटि होता है, के रूप में इन हो सकता है जब आयात कार्रवाई की जाती है या मुख्य समारोह कहा जाता है से पहले, क्रमशः। इसके विपरीत, मैं केवल उन चीजों को करता हूं जो पुस्तकालय या cmd को काम करने की इकाई की इकाई को सीधे प्रभावित नहीं करते हैं। उदाहरण के लिए, मैंने लॉगिंग सेट अप की है और गीलेर की जांच की है, हमारे पास एक सभ्य वातावरण और पैरामीटर हैं। यदि हमारे पास अवैध झंडे हैं, तो मुख्य रूप से चलाने की आवश्यकता नहीं है, है ना? और अगर हम उचित प्रतिक्रिया नहीं दे सकते हैं, तो हमें इसे जल्दी ही बताना चाहिए।
2. ... एक त्रुटि होती है जिसके बारे में मुझे पता है कि यह अपरिवर्तनीय है। आइए मान लें कि हमारे पास एक प्रोग्राम है जो कमांड लाइन पर दी गई छवि फ़ाइल का थंबनेल बनाता है। यदि यह फ़ाइल मौजूद नहीं है या अपर्याप्त अनुमतियों के कारण अपठनीय है, तो जारी रखने का कोई कारण नहीं है और यह त्रुटि पुनर्प्राप्त नहीं की जा सकती है। तो हम सम्मेलनों का पालन करते हैं और असफल होते हैं।
3. ... एक प्रक्रिया के दौरान एक त्रुटि होती है जो कि उलट नहीं हो सकती है। यह एक मुलायम परिभाषा है, मुझे पता है। मुझे इसे स्पष्ट करने दें। आइए मान लें कि हमारे पास cp का कार्यान्वयन है, और यह गैर-इंटरैक्टिव होने और एक निर्देशिका को दोबारा कॉपी करने के लिए शुरू किया गया था। अब, मान लीजिए कि हम लक्ष्य निर्देशिका में एक फ़ाइल का सामना करते हैं जिसमें एक ही नाम (लेकिन अलग-अलग सामग्री) है, जिसकी प्रतिलिपि बनाने के लिए फ़ाइल है। चूंकि हम उपयोगकर्ता से यह तय करने के लिए नहीं कह सकते कि क्या करना है और हम इस फ़ाइल की प्रतिलिपि नहीं बना सकते हैं, हमें एक समस्या है। चूंकि उपयोगकर्ता यह मान लेगा कि जब हम निकास कोड शून्य के साथ समाप्त करते हैं तो स्रोत और लक्ष्य निर्देशिका सटीक प्रतियां होती हैं, इसलिए हम फ़ाइल को प्रश्न में छोड़ नहीं सकते हैं। हालांकि, हम इसे आसानी से ओवरराइट नहीं कर सकते हैं, क्योंकि इससे संभावित रूप से जानकारी नष्ट हो सकती है।यह एक ऐसी स्थिति है जिसे हम उपयोगकर्ता द्वारा प्रति स्पष्ट अनुरोध से पुनर्प्राप्त नहीं कर सकते हैं, और इसलिए मैं स्थिति को समझाने के लिए log.Fatal का उपयोग करूंगा, इस प्रकार सिद्धांत को जल्द से जल्द विफल करने का पालन करता हूं।