قراءة الأخطاء والـ stack traces

لدى الجميع ردّ الفعل الأول نفسه تجاه الـ stack trace: تتجمّد العينان، ويهبط القلب، وتريد إغلاق التبويب. عشرون سطرًا أحمر، نصفها عن ملفات لم ترها قط، وكلها تنتهي برسالة غامضة مثل TypeError: Cannot read properties of undefined (reading 'map').

الـ stack trace هو ببساطة طريقة الحاسوب في القول «حاولتُ، وهذا بالضبط أين عَلِقتُ». وClaude يقرأ ذلك بطلاقة. أنت لستَ مضطرًّا.

هذا الدرس عن تحويل «يا للهول» إلى «آه، هذا كل ما في الأمر».

ما هو الـ stack trace فعليًا

قبل أن نُسلّمه إلى Claude، تبسيط صغير. الـ stack trace هو قائمة استدعاءات الـ functions التي كانت جارية حين حدث الخطأ — تُقرأ من الأعلى إلى الأسفل، مع أحدث استدعاء في الأعلى.

يبدو مرهبًا لأنه مطبوع لآلة، لا لإنسان: paths كاملة للملفات، وأرقام أسطر، وأسماء functions، وأحيانًا عدد مرات الاستدعاء. لكن لا يوجد فيه حقًا سوى ثلاثة أشياء:

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

يستطيع Claude استخراج الثلاثة جميعًا من أي trace، بأي لغة، فورًا.

الخطوة

تصطدم بخطأ. تبقى هادئًا. تنسخ الـ trace كاملًا — كله، بما في ذلك الأسطر الفارغة والأجزاء التي لا تفهمها — وتلصقه في Claude. الصياغة بالكاد تهمّ:

أحصل على هذا الخطأ. ماذا يعني وأين أبحث؟
I'm getting this error. What does it mean and where do I look?

[الصق الـ trace كاملًا هنا]
[paste the full trace here]

هذا كل شيء. سيقوم Claude بما يلي:

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

«النصّ المخيف» صار الآن فقرة.

لا تقتطعه

أكبر خطأ يرتكبه المبتدئون هو لصق السطر الأخير فقط. أسفل الـ trace هو حيث انطلق الخطأ، لكن أعلى الـ trace هو حيث جاء منه الخطأ. اقتطعه، وتكون قد رميتَ الجزء الذي يحتاجه Claude أكثر من غيره.

الصق الأمر كله. لا تتدخّل بتحريرٍ منك. لا تنتقِ السطر الذي تظن أنه المهمّ.

إن مرّ الـ terminal ولم ترَ سوى جزء منه، فمرّر إلى الأعلى والتقط الكتلة كاملةً — عادةً أول سطر فارغ في الأعلى هو بدايتك، والـ prompt في الأسفل هو نهايتك.

أخطاء بلا stack traces

ليس كل خطأ يأتي مع stack trace مهذّب. أحيانًا تحصل على:

رسالة غامضة في الـ terminal: «command not found» أو «port 3000 already in use».
test فاشل مع diff بين المتوقَّع والفعلي.
خطّ أحمر متعرّج في محرّرك مع تلميح.
صندوق أحمر على صفحة وِب حين جرّبتَ شيئًا.

عامِل كل هذه بالطريقة نفسها: انسخ النصّ والسياق — ما كنتَ تفعله حين حدث — واسأل Claude. السياق هو المُضاعِف.

شغّلتُ للتوّ `npm run dev` في هذا المشروع وحصلتُ على هذا. ما الخطأ؟
I just ran `npm run dev` in this project and got this. What's wrong?

[الصق الخرج]
[paste the output]

قارن ذلك بـ*«npm لا يعمل»* وسترى لماذا يهمّ السياق. (كل من سبق أن حاول مساعدة صديق في حاسوبه عبر الرسائل النصّية يعرف الفرق.)

النقطة التي تربك الناس

حين يكون الخطأ في ملف من library — لا في كودك أنت — يُصاب المبتدئون بالذعر. «لا أعرف تلك الـ library، كيف لي أن أصلحها؟»

لستَ مضطرًّا. غالبًا، خطأ آتٍ من library يعني أن كودك أنت يستخدم الـ library استخدامًا خاطئًا. سيعرف Claude ذلك ويخبرك به:

«هذا الخطأ من داخل library الـ react-query، لكنه ناتج عن استدعائك في src/pages/home.tsx:42 — أنت تمرّر undefined حيث كانت function متوقَّعة».

تلك هي الإجابة التي احتجتَها. الإصلاح في ملفك أنت، لا في الـ library. (يُسمح لك أن تشعر بالارتياح.)

لماذا يوجد هذا الدرس

يكاد كل من يتوقف عن تعلّم البرمجة يتوقف أثناء خطأ. يبدو الجدار الأحمر كأنه فشل شخصي. ليس كذلك — إنه مجرد آلة تتصرّف بحرفية.

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

بعد هذا الدرس، ينبغي أن يبدو الخطأ أقلّ شبهًا بجدار وأكثر شبهًا بباب. باب مخيف المظهر، أحيانًا. لكنه باب.

ما التالي

أحيانًا لا يكون الخطأ في ما هو موجود الآن — بل في ما تغيّر. «كان هذا يعمل أمس. ماذا فعلتُ؟» هذا سؤال عن git history، وClaude بارع فيه إلى حدّ مذهل أيضًا. الدرس التالي.