مختبر تحقق التسجيل
Signup Validation Lab
مختبر تحقق التسجيل — Signup Validation Lab
التعامل مع الأخطاء يظهر بوضوح عند استقبال بيانات من مستخدم. في هذا المختبر ستكتب تحققاً صغيراً من نموذج تسجيل.
بيانات التسجيل مثال ممتاز لأن الخطأ ليس حالة نادرة. المستخدم قد ينسى الاسم، يكتب بريداً ناقصاً، أو يختار كلمة مرور قصيرة. كود Go الجيد لا يتعامل مع هذه الحالات كاستثناءات مخفية؛ يرجع error واضحاً، ويترك للمستدعي قرار العرض أو التسجيل أو الرفض.
في هذا المختبر سنفصل بين نوع البيانات Signup ودالة التحقق validateSignup. هذا الفصل مهم لأن نفس التحقق قد يستخدم داخل HTTP handler، أمر CLI، أو اختبار. لو وضعت كل المنطق داخل main أو داخل مكان العرض، ستصعب إعادة استخدامه. سنستخدم أيضاً sentinel error باسم ErrInvalidSignup حتى يستطيع الكود الأعلى معرفة أن الخطأ من نوع “بيانات تسجيل غير صالحة” حتى لو اختلفت الرسالة التفصيلية.
المطلوب
نريد دالة validateSignup تفحص:
- الاسم غير فارغ.
- البريد يحتوي
@. - كلمة المرور طولها 8 أحرف أو أكثر.
إذا فشل أي شرط، ترجع خطأ يشرح السبب. إذا نجحت، ترجع nil.
لاحظ أن الرسائل هنا موجهة للمطور أكثر من المستخدم النهائي. في منتج حقيقي قد تعرض للمستخدم رسالة ألطف مثل “راجع البريد الإلكتروني”، بينما تحتفظ في log أو نتيجة التحقق بسبب دقيق. المهم أن الدالة لا ترجع nil إلا عندما تكون البيانات مقبولة فعلاً.
نموذج الحل التدريجي
استخدمنا strings.TrimSpace للاسم لأن الاسم المكون من مسافات فقط لا يعتبر اسماً صالحاً. واستخدمنا strings.Contains كتحقق مبسط للبريد لأننا في درس Go لا في درس قواعد البريد الكامل. في الإنتاج قد تستخدم تحققاً أدق، لكن لا تبالغ مبكراً: المطلوب هنا أن تفهم شكل دالة التحقق وكيف ترجع الأخطاء.
الجزء المهم هو %w داخل fmt.Errorf. هذه الصيغة تغلف الخطأ الأصلي وتضيف رسالة عليه. النتيجة المقروءة تصبح مثل “بيانات التسجيل غير صالحة: البريد غير صحيح”، وفي نفس الوقت يستطيع errors.Is لاحقاً أن يعرف أن الخطأ يحتوي ErrInvalidSignup.
تحدي المختبر
أكمل الدالة بحيث تميّز بين البيانات الصالحة وغير الصالحة. استخدم fmt.Errorf مع %w حتى يبقى السبب الأصلي قابلاً للفحص.
ملاحظة عملية
لا تجعل كل خطأ errors.New("failed"). في كود الإنتاج، رسالة الخطأ يجب أن تساعد المطور على تحديد السبب، بينما رسالة المستخدم النهائي يمكن أن تكون أبسط وأكثر لطفاً.
أخطاء شائعة
أول خطأ هو إرجاع نص عادي بدون تغليف الخطأ المعروف، مثل fmt.Errorf("البريد غير صحيح"). هذا يطبع رسالة مفهومة، لكنه يمنع المستدعي من استخدام errors.Is(err, ErrInvalidSignup). ثاني خطأ هو فحص كلمة المرور قبل البريد أو الاسم ثم توقع رسالة مختلفة في الاختبار. ترتيب الشروط جزء من سلوك الدالة عندما توجد أكثر من مشكلة في نفس الطلب. ثالث خطأ هو نسيان return nil في نهاية الدالة، أو إرجاع nil قبل إكمال كل الشروط.
عند مراجعة الحل، شغّل ثلاث حالات في ذهنك: بيانات صحيحة يجب أن تقبل، بريد بدون @ يجب أن يرفض، واسم فارغ بعد إزالة المسافات يجب أن يرفض. إذا كانت كل حالة تعطي نتيجة واضحة، فالدالة صارت أساساً جيداً للاستخدام داخل handler أو service.
خلاصة
التحقق الجيد في Go ليس دالة ضخمة ولا رسائل غامضة. هو سلسلة شروط واضحة ترجع أخطاء قابلة للفحص. error يخبرك أن شيئاً فشل، وfmt.Errorf مع %w يحافظ على السبب الأصلي، وerrors.Is يعطي الكود الأعلى طريقة آمنة لاتخاذ قرار. هذه مهارة ستحتاجها في HTTP، قواعد البيانات، وأي نقطة يدخل منها المستخدم بيانات إلى النظام.