L'erreur non typée, ou pourquoi catch (e) est unknown The untyped error, or why catch (e) is unknown

Le catch reçoit un unknown — parce qu'un rejet peut être n'importe quoi.The catch receives an unknown — because a reject can be anything.

Le numéro précédent l'a annoncé : Promise<T> ne dit rien de l'échec. On le constate ici, au catch. Le réflexe est d'écrire catch (e: any) et de lire e.message — comme si toute erreur était un Error. Mais en JavaScript, on peut throw n'importe quoi : une chaîne, un nombre, un objet nu. TypeScript le sait, et type donc e en unknown : impossible d'y toucher sans prouver d'abord (Vol 4.2). Le any qu'on met à la place n'est pas une solution — c'est le retour du trou, à l'endroit le plus exposé.The previous issue announced it: Promise<T> says nothing of failure. You meet it here, at the catch. The reflex is to write catch (e: any) and read e.message — as if every error were an Error. But in JavaScript, you can throw anything: a string, a number, a bare object. TypeScript knows this, and types e as unknown: you can't touch it without proving first (Vol 4.2). The any you put instead isn't a solution — it's the hole returning, at the most exposed spot.

try {
  await risky();
} catch (e: any) {            // any : on suppose une forme d'erreur
  log(e.message.toUpperCase());
}
// 💥 si le code a fait 'throw "boom"' : "boom".message est undefined → crash dans le catch

try {
  await risky();
} catch (e) {                 // e : unknown — on ne SAIT pas ce qui a été lancé
  if (e instanceof Error) {
    log(e.message.toUpperCase());   // ✓ ici e : Error — prouvé
  } else {
    log("erreur non-Error : " + String(e));   // l'autre cas, géré honnêtement
  }
}

La fausse symétrie : Result<T, E> met l'erreur dans le type. Promise<T> la cache.The false symmetry: Result<T, E> puts the error in the type. Promise<T> hides it.

Venant d'un langage à Result, on croit retrouver la même garantie : un canal d'erreur typé. C'est un piège. Result<T, E> nomme l'erreur à parité avec le succès, et le compilateur force à la traiter. Promise<T> n'a qu'un paramètre : le succès. L'erreur n'a aucune place dans le type, parce que JavaScript autorise à throw n'importe quelle valeur — pas seulement un Error. L'asymétrie n'est pas un oubli : c'est une conséquence du langage hôte. D'où le unknown au catch, irréductible.Coming from a language with Result, you expect the same guarantee: a typed error channel. It's a trap. Result<T, E> names the error on a par with success, and the compiler forces you to handle it. Promise<T> has only one parameter: success. The error has no place in the type, because JavaScript lets you throw any value — not only an Error. The asymmetry isn't an oversight: it's a consequence of the host language. Hence the unknown at the catch, irreducible.

// Rust : l'erreur est DANS la signature, à parité avec le succès.
fn get_user(id: u32) -> Result<User, DbError> { ... }
//                      ^^^^^^^^^^^^^^^^^^^^^^ T ET E, tous deux typés
// l'appelant ne peut pas lire le User sans passer par DbError (match, ?, unwrap).

Dans un Result<T, E>, l'échec a un nom, une forme, et une obligation : l'appelant doit le gérer. L'erreur fait partie du contrat. On peut croire que Promise<T> en est l'équivalent asynchrone — c'est là que l'intuition trompe.In a Result<T, E>, failure has a name, a shape, and an obligation: the caller must handle it. The error is part of the contract. You might think Promise<T> is its async equivalent — that's where intuition misleads.

throw accepte tout, donc catch ne sait rien. On rétrécit, ou on modélise.throw accepts anything, so catch knows nothing. You narrow, or you model.

La mécanique est limpide une fois posée : throw accepte n'importe quelle valeur — chaîne, nombre, objet, Error. Le catch ne peut donc rien garantir, et le drapeau useUnknownInCatchVariables (dans strict) type e en unknown plutôt qu'en any. Deux stratégies honnêtes en découlent. Réagir après coup : rétrécir le unknown avec instanceof, en gérant le cas non-Error. Ou prévenir : ne pas throw du tout pour les erreurs attendues, mais renvoyer un type qui les nomme — un Result, une union discriminée.The mechanic is clear once stated: throw accepts any value — string, number, object, Error. So catch can guarantee nothing, and the useUnknownInCatchVariables flag (in strict) types e as unknown rather than any. Two honest strategies follow. React after the fact: narrow the unknown with instanceof, handling the non-Error case. Or prevent: don't throw at all for expected errors, but return a type that names them — a Result, a discriminated union.

throw "une chaîne";        // légal
throw 42;                   // légal
throw { code: "E_OOPS" };   // légal
throw new Error("vrai");    // légal aussi
// 'throw' accepte TOUTE valeur → 'catch' ne peut rien supposer → e : unknown
// (avec useUnknownInCatchVariables, dans strict ; sinon, c'était 'any')

try {
  await risky();
} catch (e) {                          // unknown
  if (e instanceof NetworkError) retry();          // classe d'erreur dédiée
  else if (e instanceof Error) log(e.message);     // Error générique
  else log("rejet non-Error : " + String(e));      // string, objet nu, etc.
}

catch (e: any) puis e.message — la prière qui plante sur le premier rejet bizarre.catch (e: any) then e.message — the prayer that crashes on the first odd reject.

Le contre-exemple obligatoire : catch (e: any) puis lire e.message ou e.code. Ça marche tant qu'on rejette des Error bien formés — et ça plante le jour où une lib throw un string, où une API renvoie un objet sans .message, où un null remonte. On a échangé un unknown honnête contre un any qui suppose. La bonne réponse, quand on a besoin de distinguer les échecs, n'est pas de mieux deviner dans le catch : c'est de ne plus throw les erreurs attendues, et de les modéliser comme des valeurs typées.The mandatory counter-example: catch (e: any) then read e.message or e.code. It works as long as you reject well-formed Errors — and crashes the day a lib throws a string, an API returns an object with no .message, a null bubbles up. You traded an honest unknown for an any that assumes. The right answer, when you need to distinguish failures, isn't to guess better in the catch: it's to stop throwing expected errors, and model them as typed values.

async function load() {
  try {
    return await fetchUser();
  } catch (e: any) {            // ✗ any : on suppose
    if (e.code === "404") return null;   // 💥 si e est un string : e.code = undefined
    throw new Error(e.message);          // 💥 si e n'a pas .message : "undefined"
  }
}

Chaque accès — e.code, e.message — est un pari sur une forme que any n'a pas vérifiée. Un rejet inattendu (un string, un objet nu) fait planter le gestionnaire d'erreur lui-même — l'endroit censé rattraper le problème devient la source du suivant.Each access — e.code, e.message — bets on a shape any never checked. An unexpected reject (a string, a bare object) crashes the error handler itself — the place meant to catch the problem becomes the source of the next one.