TypeScript يمنحك ضمانات قوية حول العديد من أنواع المدخلات غير الصالحة.
ما لا يفعله هو تتبع الاستثناءات المرفوعة عبر برنامجك بطريقة مفيدة.
لهذا السبب، غالبًا ما تقرأ الأخطاء المتوقعة بشكل أكثر وضوحًا كبيانات بدلاً من استثناءات.
ليس كل فشل يجب أن يرفع استثناء
هناك فرق بين:
- "بوابة الدفع أعادت
card_declined"
- "عمليتنا واجهت نوعًا من العقد يجب ألا يحدث أبدًا"
الأول هو جزء من تدفق الأعمال الطبيعي.
الثاني هو استثنائي.
إذا قمت برفع استثناء لكلا الحالتين، يجب على المتصلين استنتاج الكثير من تدفق التحكم.
نوع نتيجة بسيط
لا تحتاج إلى نظرية الفئات لاستخدام الفكرة بشكل جيد. في TypeScript، يكفي أن يكون لديك اتحاد تمييزي:
type Result<T, E> =
| { ok: true; value: T }
| { ok: false; error: E };
async function fetchUser(id: string): Promise<Result<User, "NOT_FOUND" | "NETWORK_ERROR">> {
const response = await fetch(`/api/users/${id}`);
if (response.status === 404) {
return { ok: false, error: "NOT_FOUND" };
}
if (!response.ok) {
return { ok: false, error: "NETWORK_ERROR" };
}
return { ok: true, value: await response.json() };
}
الآن تخبر توقيع الدالة المتصل بأن الفشل متوقع ومصنوع.
ما الذي تكسبه
تساعد هذه الطريقة عندما:
- تكون أوضاع الفشل جزءًا من منطق المجال
- من المتوقع أن يتفاعل المتصل بشكل مختلف مع كل واحد منها
- تريد أن تكون تلك الحالات مرئية في نظام الأنواع
تصبح نقطة الاتصال واضحة:
const result = await fetchUser("123");
if (!result.ok) {
if (result.error === "NOT_FOUND") return render404();
return renderRetryState();
}
return renderProfile(result.value);
غالبًا ما يكون ذلك أسهل في المراجعة من try/catch التي تمتزج بها أخطاء النقل، وأخطاء المحلل، وفشل منطق الأعمال في كتلة واحدة.
ما الذي يجب عليك رفعه
أنواع النتائج ليست سببًا لحظر الاستثناءات.
ارفع استثناءً عندما:
- ضربت العملية انتهاكًا حقيقيًا للعقد
- استمرار التنفيذ غير آمن
- يتوقع حد إطار العمل استثناءات
نموذج كبيانات عندما:
- يكون الفشل متوقعًا
- يحتاج المتصل للتفرع بناءً عليه
- هو جزء من سلوك المنتج الطبيعي
تكون تلك القاعدة أكثر فائدة من "الاستثناءات سيئة" كقاعدة عامة.
مزيد من القراءة