Lesson 19 / الدرس 19

Handling errors / معالجة الأخطاء

What try can and cannot catch, why an empty catch is worse than no catch at all, and how to fail in a way that tells the user something true.

ما يستطيع try التقاطه وما لا يستطيع، ولماذا catch فارغة أسوأ من لا التقاط أصلًا، وكيف تخفق على نحو يقول للمستخدم شيئًا صحيحًا.

The shape, and its edges

try {
  risky();
} catch (err) {
  console.error(err);            err.message, err.name, err.stack
} finally {
  cleanUp();                     runs either way
}

throw new Error('Order not found');    always an Error, never a string

try { await load(); } catch (err) { }  await inside try: caught
setTimeout(risky, 0);                  NOT caught by any try around it

The last line is the edge that surprises people. A try catches what happens while it runs, and a callback scheduled for later runs long after the try block has finished. Press the four buttons and watch which failures the handler sees.

والسطر الأخير هو الحافة التي تفاجئ الناس. فـtry يلتقط ما يحدث أثناء عمله، وردّ النداء المجدول للاحق يعمل بعد انتهاء كتلة try بزمن طويل. اضغط الأزرار الأربعة وراقب أي الإخفاقات يراها المعالج.

Failing usefully

Instead of	Do
catch (e) { }	Handle it, or let it through — never silence it
throw "not found"	throw new Error("not found") — a string has no stack
alert(err.message)	Show the user what to do next, log the detail
try around everything	try around the one call that can fail
catch (e) { console.log(e) }	Also tell the person looking at the screen

The third row is the one that separates a finished feature from an unfinished one. err.message is written for you, not for the user: "NetworkError when attempting to fetch resource" tells them nothing they can act on. "We could not reach the server — check your connection and try again" does, and the technical message still belongs in the console where you will look for it.

والسطر الثالث هو الذي يفصل ميزة مكتملة عن غير مكتملة. فـerr.message مكتوبة لك لا للمستخدم: فـ"NetworkError when attempting to fetch resource" لا تقول له شيئًا يتصرف على أساسه. أما "تعذّر الوصول إلى الخادم — تحقق من اتصالك وحاول ثانية" فتفعل، وتظل الرسالة التقنية في الطرفية حيث ستبحث عنها.

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

Two habits that go with this. Throw Error objects rather than strings: an Error carries a stack trace saying where it came from, and a string carries nothing, so the debugging starts with a search for the text. And keep the try narrow — wrapping fifty lines means the catch cannot know which of them failed, and it will happily catch a typo in your own rendering code and report it to the user as a network problem.

وعادتان تصحبان هذا. ارمِ كائنات Error لا نصوصًا: فـError يحمل تتبّع مكدس يقول من أين جاء، والنص لا يحمل شيئًا، فيبدأ التنقيح ببحث عن النص. وأبقِ try ضيقة — فتغليف خمسين سطرًا يعني أن catch لا تعرف أيها أخفق، وستلتقط بسرور خطأً إملائيًا في شيفرة عرضك وتبلّغ به المستخدم كمشكلة شبكة.

ولما يفلت من كل شيء، مستمعان يلتقطان ما بقي: window.addEventListener("error", …) للرميات العادية، ويستخدمه البيان لإظهار إخفاق المؤقت، و"unhandledrejection" للوعود التي لم يلتقطها أحد. وفي مشروع حقيقي يذهب كلاهما إلى سجل؛ وأثناء التعلم كلاهما إلى الشاشة.

Try it live / جرّب بنفسك

<pre id="out"></pre>
<button id="go">A plain throw</button>

<script>
  const out = document.getElementById('out');
  const lines = [];
  function say(t) { lines.push(t); out.textContent = lines.join('\n'); }

  function boom() { throw new Error('the shop is closed'); }

  document.getElementById('go').addEventListener('click', function () {
    try {
      boom();
    } catch (err) {
      say('caught: ' + err.message);
    } finally {
      say('finally ran');
    }
  });
</script>

Preview / المعاينة

Check yourself / اختبر نفسك

1. Why does a try around setTimeout(risky, 0) not catch the failure?

لماذا لا يلتقط try حول setTimeout(risky, 0) الإخفاق؟

2. What is wrong with an empty catch?

ما الخطأ في catch فارغة؟

3. What should the user see when a request fails?

Your task / مهمتك

Build four buttons, each producing a different failure: a plain throw, a rejected await, a throw inside a timer, and one swallowed by an empty catch. For each, print whether your handler saw it and what the page ended up showing. Then take the swallowed case and fix it properly: catch it, log the technical detail, and put a sentence on the screen that tells a non-technical person what to do next.

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

Four different failures, each reported أربعة إخفاقات مختلفة كل منها مُبلَّغ عنه
The timer case shown escaping the try حالة المؤقت معروضة وهي تفلت من try
The swallowed case shows a wrong value with no message الحالة المبتلعة تُظهر قيمة خاطئة بلا رسالة
It is then fixed with a message a user could act on ثم مُصلَحة برسالة يستطيع المستخدم التصرف عليها