Skip to content

Commit cacfbc0

Browse files
authored
Merge pull request #288 from afilahkle/master
Error handling, "try...catch"
2 parents 8995be3 + 6ad3dc4 commit cacfbc0

File tree

3 files changed

+41
-41
lines changed

3 files changed

+41
-41
lines changed

1-js/10-error-handling/1-try-catch/1-finally-or-code-after/solution.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,8 @@
11
يصبح الفرق واضحًا عندما ننظر إلى الكود داخل دالة.
22

3-
The behavior is different if there's a "jump out" of `try...catch`.
3+
السلوك يختلف إذا كان هناك "الانتقال" من `try...catch`.
44

5-
For instance, when there's a `return` inside `try...catch`. The `finally` clause works in case of _any_ exit from `try...catch`, even via the `return` statement: right after `try...catch` is done, but before the calling code gets the control.
5+
على سبيل المثال، عند وجود `return` داخل `try...catch`. الشرط `finally` يعمل في حالة أي خروج من `try...catch`، حتى عند استخدام عبارة `return`: مباشرة بعد انتهاء `try...catch`، ولكن قبل أن يستعيد الكود السيطرة.
66

77
```js run
88
function f() {

1-js/10-error-handling/1-try-catch/1-finally-or-code-after/task.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ importance: 5
66

77
قارن بين جزئي الكود.
88

9-
1. The first one uses `finally` to execute the code after `try...catch`:
9+
1. الأول يستخدم `finally` لتنفيذ الكود بعد `try...catch`:
1010

1111
```js
1212
try {
@@ -20,7 +20,7 @@ importance: 5
2020
}
2121
```
2222

23-
2. The second fragment puts the cleaning right after `try...catch`:
23+
2. القطعة الثانية تضع عملية التنظيف مباشرة بعد `try...catch`:
2424

2525
```js
2626
try {

1-js/10-error-handling/1-try-catch/article.md

Lines changed: 37 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
1-
# Error handling, "try...catch"
1+
# التعامل مع الأخطاء، "try...catch"
22

33
بغض النظر عن مدى روعتنا في البرمجة ، في بعض الأحيان تحتوي أكوادنا على أخطاء. قد تحدث بسبب أخطائنا ، إدخال المستخدم معلومة غير متوقعة ، واستجابة خاطئة للخادم ، ولآلاف الأسباب الأخرى.
44

55
عادة "يتعطل" البرنامج في حالة حدوث خطأ (يتوقف فورًا) ، مع ظهور الخطأ في وحدة التحكم.
66

7-
But there's a syntax construct `try...catch` that allows us to "catch" errors so the script can, instead of dying, do something more reasonable.
7+
لكن هناك بناء بناء جملة يسمى `try...catch` يسمح لنا بـ "التقاط" الأخطاء حتى يمكن للنص أن يفعل شيئًا أكثر معقولية بدلاً من الانهيار.
88

9-
## The "try...catch" syntax
9+
## بناء try...catch
1010

11-
The `try...catch` construct has two main blocks: `try`, and then `catch`:
11+
يتكون بناء try...catch من مكونين رئيسيين: `try` و `catch`.
1212

1313
```js
1414
try {
@@ -20,13 +20,13 @@ try {
2020

2121
يعمل كالتالي:
2222

23-
1. First, the code in `try {...}` is executed.
24-
2. If there were no errors, then `catch (err)` is ignored: the execution reaches the end of `try` and goes on, skipping `catch`.
25-
3. If an error occurs, then the `try` execution is stopped, and control flows to the beginning of `catch (err)`. The `err` variable (we can use any name for it) will contain an error object with details about what happened.
23+
1. أولاً، يتم تنفيذ الشفرة داخل `try {...}`.
24+
2. إذا لم تحدث أخطاء، يتم تجاهل `catch (err)`، ويتم استكمال تنفيذ الشفرة داخل `try` والانتقال إلى الخطوة التالية.
25+
3. إذا حدث خطأ، فإن تنفيذ `try` يتوقف، ويتم نقل التحكم إلى بداية `catch (err)`، وستحتوي المتغير `err` (يمكن استخدام أي اسم آخر) على كائن خطأ يحتوي على تفاصيل حول ما حدث.
2626

2727
![](try-catch-flow.svg)
2828

29-
So, an error inside the `try {...}` block does not kill the script -- we have a chance to handle it in `catch`.
29+
نعم، الخطأ داخل كتلة `try {...}` لا يؤدي إلى إيقاف تشغيل البرنامج بل يتيح لنا فرصة التعامل معه في `catch`.
3030

3131
دعونا نلقي نظرة على بعض الأمثلة.
3232

@@ -64,27 +64,27 @@ So, an error inside the `try {...}` block does not kill the script -- we have a
6464
}
6565
```
6666

67-
````warn header="`try...catch`only works for runtime errors" For`try...catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
67+
````warn header="`try...catch` يعمل فقط لأخطاء وقت التشغيل" لكي يعمل `try...catch`، يجب أن يكون الكود صالحاً للتشغيل، أي يجب أن يكون JavaScript صالحاً.
6868

6969
لن يعمل إذا كان الكود خاطئًا من الناحية النحوية ، على سبيل المثال يحتوي على أقواس و معقفات ناقصة:
7070

7171
```js run
7272
try {
7373
{{{{{{{{{{{{
7474
} catch (err) {
75-
alert("The engine can't understand this code, it's invalid");
75+
alert("المحرك لا يستطيع فهم هذا الكود، فهو غير صالح");
7676
}
7777
```
7878
7979
يقرأ محرك JavaScript الكود أولاً ، ثم يشغلها. تسمى الأخطاء التي تحدث في مرحلة القراءة بأخطاء "وقت التحليل" ولا يمكن إصلاحها (من داخل هذا الكود). ذلك لأن المحرك لا يستطيع فهم الكود.
8080
81-
So, `try...catch` can only handle errors that occur in valid code. Such errors are called "runtime errors" or, sometimes, "exceptions".
81+
لذا، يمكن لـ `try...catch` فقط التعامل مع الأخطاء التي تحدث في الشفرة الصحيحة. وتسمى هذه الأخطاء "أخطاء وقت التشغيل" أو في بعض الأحيان "الاستثناءات".
8282
8383
`````
8484

8585

86-
````warn header="`try...catch` works synchronously"
87-
If an exception happens in "scheduled" code, like in `setTimeout`, then `try...catch` won't catch it:
86+
````warn header="`try...catch` يعمل بشكل متزامن"
87+
إذا حدث استثناء في الكود "المجدول"، مثل في `setTimeout`، فلن يمكن لـ `try...catch` التقاطه:
8888

8989
```js run
9090
try {
@@ -96,15 +96,15 @@ try {
9696
}
9797
```
9898

99-
That's because the function itself is executed later, when the engine has already left the `try...catch` construct.
99+
هذا لأن الدالة تنفذ في وقت لاحق، عندما يكون المحرك قد ترك بناء `try...catch`.
100100

101-
To catch an exception inside a scheduled function, `try...catch` must be inside that function:
101+
للتقاط استثناء داخل دالة مجدولة، يجب أن يتم وضع `try...catch` داخل تلك الدالة:
102102
```js run
103103
setTimeout(function() {
104104
try {
105-
noSuchVariable; // try...catch handles the error!
105+
noSuchVariable; // تتعامل الـ try...catch مع الخطأ!
106106
} catch {
107-
alert( "error is caught here!" );
107+
alert( "تم التقاط الخطأ هنا!" );
108108
}
109109
}, 1000);
110110
```
@@ -118,7 +118,7 @@ setTimeout(function() {
118118
try {
119119
// ...
120120
} catch (err) {
121-
// <-- the "error object", could use another word instead of err
121+
// <-- كائن الخطأ، يمكن استخدام كلمة أخرى بدلاً من err
122122
// ...
123123
}
124124
```
@@ -141,15 +141,15 @@ try {
141141
```js run untrusted
142142
try {
143143
*!*
144-
lalala; // error, variable is not defined!
144+
lalala; // خطأ، المتغير غير معرف!
145145
*/!*
146146
} catch (err) {
147147
alert(err.name); // ReferenceError
148148
alert(err.message); // lalala is not defined
149149
alert(err.stack); // ReferenceError: lalala is not defined at (...call stack)
150150

151-
// Can also show an error as a whole
152-
// The error is converted to string as "name: message"
151+
// يمكن أيضًا عرض الخطأ بشكل كامل
152+
// يتم تحويل الخطأ إلى سلسلة نصية باسم "name: message"
153153
alert(err); // ReferenceError: lalala is not defined
154154
}
155155
```
@@ -169,7 +169,7 @@ try {
169169
}
170170
```
171171
172-
## Using "try...catch"
172+
## استخدام "try...catch"
173173
174174
Let's explore a real-life use case of `try...catch`.
175175
@@ -329,7 +329,7 @@ try {
329329
330330
## إعادة رمي الإستثناءات
331331
332-
In the example above we use `try...catch` to handle incorrect data. But is it possible that _another unexpected error_ occurs within the `try {...}` block? Like a programming error (variable is not defined) or something else, not just this "incorrect data" thing.
332+
في المثال أعلاه، نستخدم `try...catch` للتعامل مع البيانات غير الصحيحة. ولكن هل من الممكن أن يحدث "خطأ آخر غير متوقع" داخل كتلة `try {...}`؟ مثل خطأ في البرمجة (متغير غير معرف) أو شيء آخر، وليس فقط هذا الأمر "البيانات غير الصحيحة".
333333
334334
فمثلا:
335335
@@ -348,7 +348,7 @@ try {
348348
349349
بالطبع ، كل شيء ممكن! المبرمجون يرتكبون الأخطاء. حتى في المرافق المفتوحة المصدر التي يستخدمها الملايين لعقود - فجأة يمكن اكتشاف خطأ يؤدي إلى اختراق رهيب.
350350
351-
In our case, `try...catch` is placed to catch "incorrect data" errors. But by its nature, `catch` gets _all_ errors from `try`. Here it gets an unexpected error, but still shows the same `"JSON Error"` message. That's wrong and also makes the code more difficult to debug.
351+
في حالتنا، يتم وضع `try...catch` للتقاط أخطاء "البيانات غير الصحيحة". ولكن بحسب طبيعته، يلتقط `catch` جميع الأخطاء من `try`. هنا يتم التقاط خطأ غير متوقع، ولكن ما زالت الرسالة نفسها "خطأ JSON" تظهر، وهذا خاطئ ويجعل الكود أكثر صعوبة في التصحيح.
352352
353353
**يجب أن يقوم Catch بمعالجة الأخطاء التي يعرفها و "إعادة رمي" كل الآخرين فقط.**
354354
@@ -358,11 +358,11 @@ In our case, `try...catch` is placed to catch "incorrect data" errors. But by it
358358
2. في `catch(err) {...}` نقوم بتحليل كائن الخطأ `err`.
359359
3. إذا لم نكن نعرف كيف نتعامل معها ، فنفعل `throw err`.
360360
361-
4. Catch gets all errors.
362-
5. In the `catch (err) {...}` block we analyze the error object `err`.
363-
6. If we don't know how to handle it, we do `throw err`.
361+
4. يمسك `catch` بجميع الأخطاء.
362+
5. في كتلة `catch (err) {...}`، نحلل كائن الخطأ `err`.
363+
6. إذا لم نعرف كيفية التعامل معه، فإننا نقوم بـ `throw err`.
364364
365-
Usually, we can check the error type using the `instanceof` operator:
365+
عادةً، يمكننا التحقق من نوع الخطأ باستخدام عامل `instanceof`.
366366
367367
```js run
368368
try {
@@ -410,11 +410,11 @@ try {
410410
}
411411
```
412412
413-
The error throwing on line `(*)` from inside `catch` block "falls out" of `try...catch` and can be either caught by an outer `try...catch` construct (if it exists), or it kills the script.
413+
إن رمي الخطأ في السطر `(*)` من داخل كتلة `catch` يسمح للخطأ بالخروج من `try...catch` ويمكن التقاطه إما بواسطة هيكل `try...catch` الخارجي (إذا وجد)، أو أنه يقتل النص البرمجي.
414414
415415
إذا `catch` تعالج في الواقع الأخطاء التي تعرف كيف تتعامل معها و" تتخطى "جميع الآخرين.
416416
417-
The example below demonstrates how such errors can be caught by one more level of `try...catch`:
417+
يوضح المثال أدناه كيف يمكن التقاط مثل هذه الأخطاء بمستوى آخر من `try...catch`:
418418
419419
```js run
420420
function readData() {
@@ -444,7 +444,7 @@ try {
444444
}
445445
```
446446
447-
Here `readData` only knows how to handle `SyntaxError`, while the outer `try...catch` knows how to handle everything.
447+
هنا، يعرف `readData` كيفية التعامل مع `SyntaxError` فقط، بينما يعرف `try...catch` الخارجي كيفية التعامل مع كل شيء.
448448
449449
## try...catch...finally
450450
@@ -528,7 +528,7 @@ alert( `${diff}ms مدة الإشتغال` );
528528
529529
بمعنى آخر ، قد تنتهي الدالة بـ `return` أو `throw`, وهذا لا يهم. تشتغل `finally` في كلتا الحالتين.
530530
531-
```smart header="Variables are local inside `try...catch...finally`" Please note that `result`and`diff`variables in the code above are declared *before*`try...catch`.
531+
```smart header="المتغيرات محلية داخل `try...catch...finally`" يرجى ملاحظة أن المتغيرات `result` و `diff` في الكود أعلاه تم إعلانها *قبل* `try...catch`.
532532

533533
وبخلاف ذلك ، إذا أعلنا عن `let` في `try`, فسوف تكون مرئية فقط داخلها.
534534

@@ -563,7 +563,7 @@ alert( func() ); // يعمل التنبيه أولاً من finally ، ثم هذ
563563

564564
````smart header="`try...finally`"
565565

566-
The `try...finally` construct, without `catch` clause, is also useful. We apply it when we don't want to handle errors here (let them fall through), but want to be sure that processes that we started are finalized.
566+
بناء `try...finally`، بدون شرط `catch`، مفيد أيضًا. نستخدمه عندما لا نريد التعامل مع الأخطاء هنا (نتركها تسقط)، ولكن نريد التأكد من أن العمليات التي بدأناها قد انتهت.
567567

568568
```js
569569
function func() {
@@ -584,7 +584,7 @@ function func() {
584584
المعلومات الواردة في هذا القسم ليست جزءًا من أساسيات JavaScript.
585585
```
586586
587-
Let's imagine we've got a fatal error outside of `try...catch`, and the script died. Like a programming error or some other terrible thing.
587+
لنفترض أن لدينا خطأ فادح خارج بناء `try...catch`، وتعطل النص. مثل خطأ في البرمجة أو شيء مروع آخر.
588588
589589
هل هناك طريقة للرد على مثل هذه الحوادث؟ قد نرغب في تسجيل الخطأ وإظهار شيء للمستخدم (عادةً لا يرون رسائل خطأ) ، إلخ.
590590
@@ -641,7 +641,7 @@ window.onerror = function (message, url, line, col, error) {
641641
642642
## الخلاصة
643643
644-
The `try...catch` construct allows to handle runtime errors. It literally allows to "try" running the code and "catch" errors that may occur in it.
644+
تسمح هيكلة `try...catch` بالتعامل مع أخطاء الوقت التشغيلي. وهي تسمح حرفيًا بـ "تجربة" تشغيل الكود و "التقاط" الأخطاء التي قد تحدث فيه.
645645
646646
الصيغة هي:
647647
@@ -656,7 +656,7 @@ try {
656656
}
657657
```
658658
659-
There may be no `catch` section or no `finally`, so shorter constructs `try...catch` and `try...finally` are also valid.
659+
قد لا يكون هناك جزء `catch` أو جزء `finally`، لذلك فإن الهياكل القصيرة `try...catch` و `try...finally` صالحة أيضًا.
660660
661661
كائنات الخطأ لها الخصائص التالية:
662662
@@ -670,4 +670,4 @@ If an error object is not needed, we can omit it by using `catch {` instead of `
670670
671671
_إعادة الرمي_ هو نمط مهم جدًا في معالجة الأخطاء: عادة ما تتوقع `catch` وتعرف كيفية التعامل مع نوع الخطأ المعين, لذلك يجب أن تقوم بإعادة رمي الأخطاء التي لا تعرفها.
672672
673-
Even if we don't have `try...catch`, most environments allow us to setup a "global" error handler to catch errors that "fall out". In-browser, that's `window.onerror`.
673+
حتى إذا لم يكن لدينا `try...catch`، فإن معظم البيئات تسمح لنا بإعداد معالج خطأ "عام" للقبض على الأخطاء التي تحدث بشكل خارجي. في المتصفح، هذا يعني استخدام `window.onerror`.

0 commit comments

Comments
 (0)