unstable_rethrow

unstable_rethrow puede utilizarse para evitar capturar errores internos lanzados por Next.js al intentar manejar errores generados en el código de tu aplicación.

Por ejemplo, llamar a la función notFound lanzará un error interno de Next.js y renderizará el componente not-found.js. Sin embargo, si se usa dentro de un bloque try/catch, el error será capturado, impidiendo que se renderice not-found.js:

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)
  }
}

Puedes usar la API unstable_rethrow para relanzar el error interno y continuar con el comportamiento esperado:

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)
  }
}

Las siguientes APIs de Next.js dependen de lanzar un error que debería ser relanzado y manejado por el propio Next.js:

• notFound()
• redirect()
• permanentRedirect()

Si un segmento de ruta está marcado para lanzar un error a menos que sea estático, una llamada API dinámica también lanzará un error que no debería ser capturado por el desarrollador. Ten en cuenta que el Renderizado Parcial Previo (PPR) también afecta este comportamiento. Estas APIs son:

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

Es bueno saber:

• Este método debe llamarse al principio del bloque catch, pasando el objeto de error como único argumento. También puede usarse dentro de un manejador .catch de una promesa.
• Si te aseguras de que tus llamadas a APIs que lanzan errores no estén envueltas en un try/catch, entonces no necesitas usar unstable_rethrow
• Cualquier limpieza de recursos (como limpiar intervalos, temporizadores, etc) debería hacerse antes de llamar a unstable_rethrow o dentro de un bloque finally.