تصميم Error Handling موحد في الأنظمة الكبيرة

الخطأ يحتاج عقدًا عامًا وسببًا داخليًا

توحيد Error Handling لا يعني إعادة JSON نفسه لكل فشل؛ بل أن يستطيع المستدعي التمييز بثبات بين خطأ التحقق والتفويض ورفض العمل وعدم وجود المورد والتعارض وفشل الاعتماديات والخطأ غير المتوقع، مع بقاء سياق داخلي كافٍ للتحقيق.

ابدأ بتصنيف الأخطاء

• استخدم Error Codes ثابتة للآلة منفصلة عن الرسائل المترجمة.
• حوّل أخطاء Domain/Business عمدًا إلى دلالات HTTP بدل رمي Exceptions خاصة بالFramework من Domain.
• أضف Correlation ID للاستجابة والسجلات ولا تعرض Stack Trace أو الأسرار.
• احتفظ بالسبب الأصلي داخليًا عند تغليف أخطاء الاعتماديات.
• وثق قابلية الإعادة؛ خطأ Validation وDependency Timeout يحتاجان سلوك عميل مختلفًا.

من السبب الداخلي إلى استجابة API

تحتفظ الأخطاء الداخلية بالأسباب الغنية، بينما يحولها حد الـAPI إلى Envelope عام ثابت وآمن وتحتفظ المراقبة بسياق التحقيق.

التعامل مع Timeout لخدمة خارجية

عادات تخفي إشارة الخطأ

قائمة عقد الأخطاء

• انشر Error Code Catalog لمستهلكي API.
• حدد HTTP Mapping وقابلية الإعادة لكل فئة.
• مركز إنشاء Public Error Envelope.
• احتفظ بالسبب وCorrelation داخليًا.
• اختبر تنقيح البيانات الحساسة ومسارات الفشل الممثلة.