تحليل رسالة خطأ PHP

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

عند تجميع برنامج PHP النصي، يبذل مترجم PHP قصارى جهده للإبلاغ عن المشكلة الأولى التي يواجهها. وهذا يخلق مشكلة: لا يمكن لـ PHP التعرف على الخطأ إلا عند حدوثه (يتم وصف هذه المشكلة بالتفصيل لاحقًا في هذه المقالة). ولهذا السبب يشير المترجم إلى أن السطر المخطئ قد يبدو ظاهريًا صحيحًا نحويًا، أو قد يكون سطرًا غير موجود على الإطلاق!

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

كيف يعمل المترجم

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

إعلان المتغير

إذا قمت بتعريف متغير في عبارة، فإن الطريقة المحددة هي كما يلي:
$متغير = 'القيمة';
يقوم المترجم أولاً بتقييم النصف الأيمن من العبارة (أي كل شيء على يمين علامة المساواة). في بعض كتب البرمجة، يتم تمثيل ذلك على أنه RHS (النصف الأيمن) من العبارة. هذا الجزء من البيان هو الذي يسبب الأخطاء غالبًا. إذا كنت تستخدم بناء جملة غير صحيح، فسوف تحصل على خطأ في التحليل.

في التحليل

: خطأ تحليل، T_WHILE غير متوقع في c:program filesApache groupApachehtdocsscript.PHP في السطر 19.

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

بالإضافة إلى ذلك، تحتوي أخطاء التحليل على معلومات قليلة جدًا، مع عدم وجود أي تقارير تقريبًا عن رقم السطر الذي حدث فيه الخطأ. السبب المحدد هو أنه عند حدوث خطأ، يحدد المترجم أن بناء جملة عدة أسطر يجب أن يبدو صالحًا حتى يواجه بناء جملة غير صالح. الحالة الأكثر احتمالًا هي استخدام كلمات محددة مسبقًا في التعبير، على سبيل المثال، while = 10 // Bad ? while هي كلمة محددة مسبقًا ولا يمكن تعيينها لقيمة.

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

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

<?PHP
$b = "قيمة ما"
إذا($b == "بعض القيمة"){
طباعة "مرحبا بالعالم!";
}
?>

الخطأ موجود في السطر "$b=" (فاصلة منقوطة مفقودة في نهاية العبارة)، لذا يجب أن يكون الخطأ "خطأ في التحليل: فاصلة منقوطة مفقودة في السطر 3" أليس كذلك؟ بدلاً من الحكم من خلال المحلل اللغوي:

خطأ في التحليل: خطأ في التحليل، T_IF غير متوقع في c:program filesApache
groupApachehtdocsereg2.PHP على السطر 4
في السطر 4، بناء جملة عبارة if() صحيح. إذًا، ما الذي يربك المترجم؟ الدليل هو الجزء "T_IF غير المتوقع". عندما يحدث خطأ "T_؟؟؟" غير متوقع، فهذا يعني: وجد المترجم أن كلمة محددة مسبقًا تظهر في موضع لا ينبغي أن تظهر فيه. يمثل T_IF if()، ويمثل T_WHILE while()، ويمثل T_FOR for()، وما إلى ذلك.
ولحسن الحظ، فإن أسباب بعض الأخطاء بسيطة أيضًا:
لا يتم إنهاء البيانات بفاصلة منقوطة (؛)، كما في المثال أعلاه. علامات الاقتباس مفقودة في السلسلة.

بعض الأخطاء الشائعة الأخرى

الخطأ الأكثر شيوعًا الذي أراه هو عدم إغلاق دالة أو حلقة باستخدام قوس ( } ) ربما يكون هذا هو الخطأ الأكثر شيوعًا وإزعاجًا. الكود المحدد هو كما يلي:

function UselessFunction() {
ل($i < 0; $i < 10; $i++){
}

سيتم إنشاء الخطأ التالي:

خطأ في التحليل: خطأ في التحليل، $ غير متوقع في c:program filesApache
groupApachehtdocsereg2.PHP على السطر 9
بما أن الدالة UselessFunction لا تنتهي بقوسين (})، فإن مترجم PHP يستمر في البحث عن قوس الإغلاق حتى يصل إلى نهاية الملف. نظرًا لأن المترجم لم يعثر على قوس مطابق، فإنه يُبلغ عن خطأ في نهاية الملف.

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

خطأ MySQL هناك

رسالة خطأ أخرى مزعجة للغاية وهي خطأ MySQL الأكثر شيوعًا، والذي غالبًا ما يسبب صداعًا لمستخدمي PHP الجدد: تحذير: الوسيطة المقدمة ليست مورد نتائج MySQL صالحًا في...
قد يكون السطر الخاطئ المذكور أعلاه هو:
بينما($row = MySQL_fetch_array($result)) {
المعلمة $result ليست موردًا صالحًا. باللغة الإنجليزية يعني ذلك أنه لا يمكن معالجة mysql_fetch_array بسبب فشل الاستعلام. بناء جملة أي من الاستعلامين غير صالح (يجب عليك نسخ الاستعلام ولصقه في مرجع وحدة تحكم MySQL للاختبار)، أو فشل الاتصال بقاعدة البيانات (وفي هذه الحالة يجب عليك التحقق مرة أخرى من اسم المستخدم وكلمة المرور وما إلى ذلك).

منع الأخطاء

كخطوة أولى، يمكن للمبرمجين الأذكياء اتخاذ الخطوات التالية لإزالة الأخطاء التالية:

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

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