السلام عليكم،
دعونا بدايةً نقرّ بأنه لا يوجد نظام أو تطبيق أو برنامج يخلو من الأخطاء "من يعرف نظام التشغيل Windiws 98 في نسخته الأولى؟". بل الخطأ هو صفةٌ لازمة لبني البشر وكل ما يفعلوه، وهي السبيل للتعلم الممنهج والتطوير المستمر، وقد عرّف الدكتور نجيب الرفاعي ذات مرة الخبير بأنه "أكثر الناس اقترافاً للأخطاء"، والحديث هنا عن الأخطاء المهنية لا الأخلاقية ولا شك. ومطورو البرامج لا يشذون عن هذه القاعدة ولا يخرجون عنها قيد أنملة،
أنت تكتب برنامجا = أنت تقترف أخطاء.
لكن العبرة ليست بقلة اقتراف الأخطاء البرمجية أو تفادي أسبابها، وإنما بالقدرة على التعاطي معها. والتعامل مع الأخطاء Error Handling واحدٌ من أهم المواضيع التي ينبغي على المبرمج المحترف التعامل معها بشكل جاد وبطريقة علمية وعملية على حدٍ سواء، بل إني أكاد أن أجزم أن معالجة الأخطاء والتحكم فيها قد تكون أحد النقاط الفاصلة بين المحترفين والهواة.
ولا يكفي لمطور تطبيقات Access أن يضع سطر حدث في أعلى الإجراء وسطر تسمية في أسفله حتى يكون بذلك قد نجح في التعامل مع الخطأ. بل هذه الصورة على أهميتها ليست إلا مدخلاً في التعامل مع الخطأ. والواجب على المطور أن يعرف تطبيقه من الرأس إلى القدمين، ومن القلب إلى الأطراف، أو كما يُقال في الإنجليزية Inside Out . جزءٌ كبير من هذه المعرفة ينبغي أن يُغطي الأخطاء التي حدثت وقت تشغيل التطبيق وتلك التي قد تقع في المستقبل. والمسالة برمتها ليست إلا ممارسة وخبرة، كلما تكررت الممارسة تعاظمت الخبرة؛ كتفاً بكتف.
لكن التحدي الحقيقي أمام المطور أنه يطور تطبيقاً لا يستخدمه هو! بالضبط كأحمد منصور مذيع قناة الجزيرة الشهير، والذي اعترف ذات مرة بأنه لا يُتابع التلفزيون، ولا يعرف كثيراً كيف تكون برامجه بعد أن ينتهي منها!
المطور ينتهي من بناء برنامجه، ثم يُرسله إلى المستخدمين للعمل عليه. المستخدمون بدورهم هم من يعيشون مع البرنامج بحلوه ومره. وإذا أخذنا الميل الجِبِلِيّ لابن آدم إلى السخط من كل شيء، حتى من نعم الله تبارك وتعالى، عرفنا السبب الذي يدفع المستخدم لأن يقول بعد أن يظهر له أي خطأ في البرنامج - أو رسالة غريبة: "زبالة". وربما سمعت من صديق العمل الغاضب على المكتب المجاور لمكتبك يقول لجهازه "لا أبوك لا أبو من سواك برنامج"، وإذا كان المتسخط إنجليزيا فقد تسمع شيئاً مثل Rubbish، أما إذا كان أمريكياً فلربما سعمت شيئاً يبدأ بـ Garbage ، وينتهي بـ Bullshit .
أياً كانت "الشتائم" والـ "قواذع"، فليست من المفترض أن تُثني المطور عن تحسين تطبيقه وتنقيحه وتطويره. لكن المسألة ليست بهذه السهولة. المستخدمون في العادة ليسوا مطورين ولا محترفي آكسس أو سيكويل أو غيره، فهذا في الغالب ليس تخصصهم. وعليه، فالمشاكل التي تقابلهم قد لا يستطيعون توضيحها بلغة يفهمها المطور، أو يفهم منها مالذي حدث بالضبط. وربما كان الوصف الوحيد الذي يجيده المستخدم حين تسأله عن الخطأ في التطبيق هو "الشبكة خربانة"، هذه العبارة الأخيرة هي الاختزال الأسهل والأبسط لأي مشكلة يُقابلها المستخدم، حتى لو كانت - كالعادة - عراكاً زوجياً مُبكراً قبل خروجه إلى العمل.
مايلزمنا كمطورين نهتم بتطبيقاتنا وتصحيحها وتنقيحها من العثرات البرمجية Bugs هو جمع أكبر قدر ممكن من المعلومات عن الخطأ، حتى وإن لم يستطع المستخدم توضيح الخطأ وكيف وقع وأين وقع وماذا ظهر له على الشاشة. هذه المعلومات سوف تساعدنا بمشيئة الله على تصحيح أخطاء التطبيق وربما كانت فرصة للتطوير والتحسين.
ماذا نُريد أن نعرف عن الخطا؟
الكثير!
نريد أن نعرف رقم الخطأ، ووصفه، ومتى وقع "الوقت والتاريخ"، وأين وقع "الوحدة Module"، وأي إجراء "الدالة أو الإجراء الفرعي"، واسم المستخدم الذي وقع له الخطأ. ثم نريد أن نحتفظ بسجل لجميع الأخطاء التي وقعت. نُريد أن نظهر رسالةً ودية للمستخدم، تُخبره بوجود خطأ ما، وعليه الإتصال بمدير النظام أو المطور على هاتفه أو بريده الإلكتروني؛ فقط.
وهذا ما يفعله المثال التالي المرفق.
تقوم فكرة المثال على جزئين؛ وحدة نمطية وجدول. بنيتُ الجدول بشكل مستقل داخل قاعدة البيانات واسمه Errors ، يحتوي على الحقول اللازمة لرصد الأخطاء "رقم تعريفي، رقم الخطأ، وصفه، تاريخه، وقته، الإجراء، الوحدة النمطية، اسم المستخدم". هذه المعلومات كافية للإجابة على الأسئلة الأكثر إلحاحا؛ أين ومتى وقع الخطأ ومَن مِن المستخدمين حدث معه الخطأ.
الجزء الثاني وهو الوحدة النمطية، وتحوي إجراءً اسمه LogError يُستدعى في أي وقت داخل التطبيق من خلال حدث التعاطي مع الخطأ Error Handler ، والذي يرصد كل المعلومات التي نحتاجها في جدول الأخطاء.
والآن، كل ما يلزمك عمله تحت كل إجراء داخل تطبيقك أن تُعيد تعريف حدث الخطأ On Error ليستدعي الإجراء LogError ويُلقمه المتغيرات المطلوبة لرصدها في قاعدة البيانات.
On Error Goto Err_Handler
'
'
'
'
'
Err_Handler:
LogError Err.Number, Err.Description, DateValue(Now()), TimeValue(Now()), "TestErr1", Application.VBE.ActiveCodePane.CodeModule, Environ("USERNAME")
MsgBox "نأسف لحدوث خطأ غير متوقع. نرجو الإتصال بالسيد عبدالحفيظ للمساعدة", vbCritical, "رسالة خطأ"
Resume Nextالجزء الأخير في التحكم Err_Handler لا يحتاج إلا إلى نسخه وتكرار لصقه في كل دالة أو روتين فرعي تشعر أنه من الضروري رصد أحداث الخطأ فيه. تأكد أنك تُمرر إسم الإجراء/الروتين في دالة رصد الخطأ ضمن البراميترز. السطر الثاني ليس إلا رسالة لطيفة تُخبر المستخدم أن شيئاً ما ليس على ما يُرام، وعليه الإتصال بفلان بن علان للمزيد للدعم الفني، ضع في صندوق الرسائل هذا ما يروق لك.
وضعتُ لك عزيزي القاريء نموذجاً بأخطاء برمجية متعمدة ليستنى لك تجربة القاعدة المثال المُرفقة. بقيت ملاحظة أخيرة، روتين رصد الخطأ جعلتُ من نسختين؛ واحدة تستخدم تقنية DAO ، والثانية لعشاق ADO وأنا منهم بالتأكيد. إذا أحببت استخدام روتين LogError2 فتأكد أنك فعلت الإشارة المرجعية في بيئة فيجوال بيزك في Tools ثم References ثم Microsoft ActiveX Data Object 2.8 .
أخي القاريء الكريم، أرجو أن تُلاحظ أن كل ماذكر أعلاه ليس إلا جهداً بشرياً منقوصاً عُرضة للصواب والخطأ، فإن أصبت فمن الله وإن أخطأت فمن نفسي والشطان، ولا غنى عن التصويب والتصحيح والتعليقات.
أطيب الأماني، وبالتوفيق للجميع،
عبدالله،،،