نقوم بإجراء تدقيق الأخطاء

العقد المستخدم بشكل متكرر للوظائف التي تُرجع قيمة خطأ لنوع الواجهة هو أن المتصل لا يحتاج إلى معرفة أي شيء مقدمًا عن حالة القيم الأخرى التي يتم إرجاعها بواسطة هذه المكالمة دون التحقق أولاً من الخطأ.

في معظم الحالات ، يجب أن تكون قيم الخطأ التي يتم إرجاعها بواسطة الدالات غير شفافة للمتصل. أي أن الاختبار الذي يكون فيه الخطأ لا شيء يوضح ما إذا كانت المكالمة ناجحة أو فاشلة ، وهذا كل ما عليك القيام به.

الصورة من هنا

يتطلب عدد صغير من الحالات ، المرتبطة عادة بالتفاعلات مع العالم الخارجي ، مثل نشاط الشبكة ، المتصل لفحص طبيعة الخطأ من أجل تقرير ما إذا كان يجب تكرار العملية.

من المتطلبات الشائعة لمؤلفي الحزم إرجاع أخطاء النوع العام المعروفة حتى يتمكن المتصل من استخدام تأكيد النوع وفحصها بالتفصيل. أعتقد أن هذه الممارسة تؤدي إلى عدد من النتائج غير المرغوب فيها:

• تزيد أنواع الأخطاء المفتوحة من "منطقة الاتصال" مع واجهة برمجة تطبيقات الحزمة.
• يجب أن ترجع التطبيقات الجديدة فقط الأنواع المحددة في إعلان الواجهة ، حتى لو لم تكن مناسبة بشكل جيد.
• نوع الخطأ ، بعد إضافته إلى الكود ، لا يمكن تغييره أو إهماله دون كسر التوافق ، مما يجعل واجهة برمجة التطبيقات هشة.

تأكيد السلوك المتوقع ، وليس نوع الخطأ

لا تدعي أن قيمة الخطأ هي نوع معين ، بل تدعي أن القيمة تنفذ سلوكًا معينًا.

تتوافق هذه الجملة مع طبيعة واجهات Go الضمنية ، وليست [نوع فرعي] من طبيعة اللغات القائمة على الميراث. النظر في هذا المثال:

func isTimeout(err error) bool { type timeout interface { Timeout() bool } te, ok := err.(timeout) return ok && te.Timeout() } 

يمكن للمتصل استخدام isTimeout () لتحديد ما إذا كان قد تم إنهاء مهلة الخطأ عن طريق تطبيق واجهة المهلة ، ثم تأكيد ما إذا كان الخطأ قد انتهى - كل ذلك دون معرفة أي شيء عن النوع أو المصدر قيم الخطأ.

تتيح هذه الطريقة التفاف الأخطاء ، كقاعدة عامة ، مع المكتبات التي تضيف تفسيرات إلى مسار الخطأ ؛ شريطة أن تقوم أنواع الأخطاء الملتفة أيضًا بتنفيذ واجهات الخطأ التي يتم التفافها.

قد يبدو هذا مشكلة غير قابلة للذوبان ، لكن في الممارسة العملية ، هناك عدد قليل من أساليب الواجهة المقبولة عمومًا ، لذلك سيغطي Timeout () bool و Temporary () bool نطاقًا واسعًا من حالات الاستخدام.

في الختام

تأكيد السلوك المتوقع ، وليس نوع الخطأ

للمؤلفين الحزمة

إذا كانت الحزمة الخاصة بك تولد أخطاء ذات طبيعة مؤقتة ، فتأكد من إرجاع أنواع الأخطاء التي تقوم بتطبيق أساليب الواجهة المناسبة. إذا قمت بالالتفاف على قيم خطأ الإخراج ، فتأكد من أن الأغلفة تدعم الواجهة (الواجهات) التي يتم بها تنفيذ قيمة الخطأ الأصلية.

لمستخدمي الحزمة

إذا كنت بحاجة إلى التحقق من وجود خطأ ، فاستخدم الواجهات لتأكيد السلوك المتوقع ، وليس نوع الخطأ. لا تسأل مؤلفي الحزمة عن أنواع الأخطاء المفتوحة ؛ اطلب منهم محاذاة أنواعهم مع الواجهات الشائعة عن طريق تحديد أساليب Timeout () أو Temporary () ، حسب الاقتضاء.

عن المؤلف

مؤلف هذا المقال ، ديف تشيني ، مؤلف العديد من الحزم الشائعة لـ Go ، على سبيل المثال ، https://github.com/pkg/errors و https://github.com/davecheney/httpstat .

من المترجم

على الرغم من أن المقالة الأصلية مؤرخة حتى نهاية عام 2014 ، يبدو لي أنها لم تفقد أهميتها. تم العثور على النهج الموصوف في حزم قليلة ، بينما يستخدم الباقي الطريقة المعتادة للأخطاء.

تعديلات على النص لزيادة وضوح المواد هي موضع ترحيب!