بعد سنوات عديدة من الخبرة في php و js ، اعتدت أن أواجه خطأ في تتبع المكدس وأنظر إلى المكان الذي حدث فيه الخطأ مباشرةً من تقرير الخطأ. الاستئناف على Go قبل عامين ، فوجئت إلى حد ما بأن Go لديها قواعد مختلفة وتحتاج إلى تخمين تتبع المكدس على سطر ما مثل "شخصية غير صالحة". وإذا حدث ذلك على المنتج ولم يعرف كيفية إعادة إنتاجه ، فقد تحول هذا إلى نقطة جذب كاملة.
نظرًا لأنني متأكد من عدم وجود أحد يعاني من هذا ، فقد قدمت حزمة يمكن القيام بذلك:

→
جيثبكل ما يفعله هو:
- يضيف تتبع المكدس إلى الأخطاء.
- يعرض تتبع المكدس وشظايا المصدر حيث حدث هذا الخطأ (في وجود المصدر ، بالطبع).
مضيفا تتبع المكدس
هناك عدة طرق لإنشاء خطأ باستخدام تتبع مكدس:
عندما يتم إعادة التفاف الخطأ ، سيبقى تتبع المكدس كما هو ولن يتم الكتابة فوقه ، فهذا مناسب إذا لم يكن معروفًا ما إذا كان الخطأ يحتوي بالفعل على تتبع مكدس أم لا.
قد يبدو الرمز كالتالي:
func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data)
عرض تتبع المكدس
بعد الخطأ خلال 100500
if err != nil { return err }
ترجع إلى موطنها في
main()
(أو حيث تتم معالجتها) ، على الأرجح سوف ترغب في عرضها أو تعهدها.
هناك عدة خيارات لهذا: كل شيء يعمل كـ Print (طباعة النص) أو Sprint (إرجاع النص):
1) عرض نص الخطأ وتتبع المكدس:
tracerr.Print(err)
2) عرض نص الخطأ ، تتبع المكدس وشظية المصدر (6 خطوط افتراضيا):
tracerr.PrintSource(err)
3) الشيء نفسه ، ولكن في اللون ، وعادة ما تكون أكثر إفادة:
tracerr.PrintSourceColor(err)
4) يمكنك تمرير كم عدد سطور التعليمات البرمجية لعرضها كمعلمة:
tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9)
5) أو تمرير 2 المعلمات الاختيارية ، وكم قبل وكم بعد السطر مع الخطأ لعرض:
tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2)
أسئلة
لقد تلقيت بالفعل بعض الملاحظات ، لذلك أسمح لنفسي بالإجابة مسبقًا على بعض الأسئلة التي تم طرحها بالفعل.
س: هل هذا مناسب فقط لتصحيح الأخطاء؟ هناك مصحح أخطاء.ج: هذا مناسب ليس فقط للتصحيح ، بل من الممكن تسجيل الأخطاء بمعلومات حول تتبع المكدس ، وحتى مع أجزاء من أكواد المصدر ، على prod ، كما في تجربتي ، سوف يسهل ذلك إلى حد كبير تحليل هذه الأخطاء.
س: هناك حزمة سوبر pkg / أخطاء ، لماذا لا تستخدمها؟ج: نعم ، أنا شخصياً استخدمته بالكامل وأنا سعيد ، لكنه لم يناسبني لهذه الأسباب:
1) لا توجد طريقة سهلة لعرض تتبع المكدس على الفور مع المصدر.
2) عندما يتم إعادة التفاف الخطأ (على سبيل المثال ، مستوى واحد أعلى) ، يتم الكتابة فوق تتبع المكدس بأخرى أقل إفادة.
3) لا بد من إرسال نص خطأ إضافي مع كل منعطف ، والذي يبدو لي أن بعض النفقات العامة عند كتابة / قراءة التعليمات البرمجية.
س: في Go ، الأخطاء ليست استثناءات ولا يمكنك القيام بذلك على الإطلاق.ج: أوافق ، الأخطاء في Go ليست استثناء. إذا كنت تفضل معالجة الآلاف
if err != nil { return err }
بطريقة أخرى - هذا هو اختيارك ، بالطبع. يمكنك فقط التفاف الأخطاء التي تقوم بمعالجتها كاستثناءات.
س: Stectrace يضيف النفقات العامة إلى الأداء.ج: نعم ، يضيف ، لكن هذا مهم فقط للأماكن التي يتم فيها إنشاء الأخطاء بكميات ضخمة ، فقط لا تقم بإضافة تتبع مكدس هناك إذا كان حرجًا (أنا متأكد من أن هذه النفقات العامة لا تذكر في معظم الحالات).
بشكل عام ، آمل أن تجعل هذه الحزمة حياتك أكثر سهولة ، وسأكون سعيدًا بأي تعليق ، شكرًا.