Le problème des erreurs levées
Comprendre pourquoi les exceptions dissimulent les échecs au système de types.
Le problème des erreurs levées est une leçon TypeScript Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage TypeScript Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours TypeScript Academy comprend 4 leçons au total.
Les exceptions sont invisibles
Lorsqu'une fonction utilise throw, sa signature ne le précise pas. Le système de types ne peut pas voir quelles fonctions sont susceptibles d'échouer ; les appelants ne reçoivent donc aucune incitation du compilateur à gérer les erreurs.
Une fonction qui lève des exceptions
Cette fonction semble toujours renvoyer un nombre, mais elle peut lever une exception. Le type de retour number masque complètement le cas d'échec.
function parsePort(s: string): number {
const n = Number(s);
if (Number.isNaN(n)) throw new Error("bad port");
return n;
}
console.log(parsePort("8080")); // 8080Les appelants oublient d'intercepter les erreurs
Rien n'oblige l'appelant à entourer l'appel de try/catch. Cette erreur est acceptée par le compilateur et n'apparaît qu'au moment de l'exécution, sous la forme d'un plantage.
const port = parsePort("oops");
// No compile error; throws at runtime, possibly crashing the app.try/catch fait perdre le type
Même lorsque vous interceptez l'erreur, la valeur interceptée est typée unknown (ou any). La structure de l'erreur n'est pas suivie, et sa gestion relève donc de la conjecture.
try {
parsePort("x");
} catch (e) {
// e: unknown -> you must narrow it manually
}Les erreurs sous forme de valeurs
L'alternative consiste à faire de l'échec une valeur ordinaire que la fonction renvoie, plutôt qu'une exception qu'elle lève. Le type de retour présente alors honnêtement les deux issues.
Un schéma renvoyant une valeur
Au lieu de lever une exception, renvoyez un objet étiqueté décrivant la réussite ou l'échec. L'appelant doit l'inspecter avant d'utiliser la valeur.
type ParseResult =
| { ok: true; value: number }
| { ok: false; error: string };Le type reflète désormais la réalité
Une fonction qui renvoie ParseResult indique explicitement qu'elle peut échouer. Le compilateur oblige alors l'appelant à gérer la branche d'échec.
function parsePort(s: string): ParseResult {
const n = Number(s);
return Number.isNaN(n)
? { ok: false, error: "bad port" }
: { ok: true, value: n };
}Gestion imposée
Comme la valeur peut appartenir à l'une ou l'autre branche, vous ne pouvez pas lire value sans vérifier d'abord ok. Le compilateur affine le type uniquement après cette vérification.
const r = parsePort("oops");
if (r.ok) console.log(r.value);
else console.log("failed:", r.error);Les exceptions ont toujours leur place
Les échecs réellement inattendus et irrécupérables (bogues de programmation, mémoire insuffisante) peuvent toujours lever une exception. Les erreurs sous forme de valeurs sont particulièrement adaptées aux échecs attendus, comme l'analyse syntaxique et la validation.
L'explicite plutôt que l'implicite
Renvoyer les erreurs rend le chemin d'échec explicite dans le type, visible au point d'appel et impossible à ignorer par accident, contrairement à un throw caché.
Vers les types Résultat et Option
Cette structure étiquetée de réussite ou d'échec se généralise en un type Résultat réutilisable, tandis que la distinction entre absence et présence se généralise en Option ; ces deux notions sont présentées ensuite.
Vérification rapide
Vérification rapide de cette leçon.
Récapitulatif
Les erreurs levées sont invisibles pour les types : les signatures masquent les échecs et les appelants oublient de les intercepter. Renvoyer l'échec sous forme de valeur explicite (un objet étiqueté représentant une réussite ou une erreur) rend le chemin d'échec visible dans le type et impossible à ignorer, ce qui mène aux types Résultat et Option.
Questions Fréquemment Posées
La leçon « Le problème des erreurs levées » est-elle gratuite ?
Oui — le texte complet de « Le problème des erreurs levées » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours TypeScript Academy, passe à CoddyKit PRO. Le cours TypeScript Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Le problème des erreurs levées » ?
Comprendre pourquoi les exceptions dissimulent les échecs au système de types. Tu pratiques TypeScript Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer TypeScript Academy ?
Aucune expérience préalable n'est requise. TypeScript Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Le problème des erreurs levées » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon TypeScript Academy ?
Oui. Chaque leçon TypeScript Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Le problème des erreurs levées
- Modéliser les types Result
- Types Option et Maybe
- Programmation orientée flux