unstable_rethrow | Next.js

unstable_rethrow peut être utilisé pour éviter d'intercepter les erreurs internes lancées par Next.js lors de la gestion des erreurs générées par votre code applicatif.

Par exemple, l'appel de la fonction notFound lancera une erreur interne de Next.js et affichera le composant not-found.js. Cependant, si elle est utilisée dans un bloc try/catch, l'erreur sera interceptée, empêchant l'affichage de not-found.js :

@/app/ui/component.tsx

import { notFound } from 'next/navigation'

export default async function Page() {
  try {
    const post = await fetch('https://.../posts/1').then((res) => {
      if (res.status === 404) notFound()
      if (!res.ok) throw new Error(res.statusText)
      return res.json()
    })
  } catch (err) {
    console.error(err)
  }
}

Vous pouvez utiliser l'API unstable_rethrow pour relancer l'erreur interne et poursuivre le comportement attendu :

@/app/ui/component.tsx

import { notFound, unstable_rethrow } from 'next/navigation'

export default async function Page() {
  try {
    const post = await fetch('https://.../posts/1').then((res) => {
      if (res.status === 404) notFound()
      if (!res.ok) throw new Error(res.statusText)
      return res.json()
    })
  } catch (err) {
    unstable_rethrow(err)
    console.error(err)
  }
}

Les API Next.js suivantes reposent sur le lancement d'une erreur qui doit être relancée et gérée par Next.js lui-même :

Si un segment de route est marqué pour générer une erreur sauf s'il est statique, un appel d'API dynamique lancera également une erreur qui ne devrait pas être interceptée par le développeur. Notez que le Prérendu Partiel (PPR) affecte également ce comportement. Ces API sont :

cookies
headers
searchParams
fetch(..., { cache: 'no-store' })
fetch(..., { next: { revalidate: 0 } })

Bon à savoir :

Cette méthode doit être appelée en haut du bloc catch, en passant l'objet d'erreur comme seul argument. Elle peut également être utilisée dans un gestionnaire .catch d'une promesse.

Si vous vous assurez que vos appels aux API qui lancent des erreurs ne sont pas encapsulés dans un try/catch, vous n'avez pas besoin d'utiliser unstable_rethrow.

Tout nettoyage de ressources (comme l'effacement d'intervalles, de minuteries, etc.) doit être effectué avant l'appel à unstable_rethrow ou dans un bloc finally.