unstable_rethrow

unstable_rethrow kann verwendet werden, um interne Fehler zu vermeiden, die von Next.js geworfen werden, wenn versucht wird, Fehler im Anwendungscode zu behandeln.

Beispielsweise wird beim Aufruf der notFound-Funktion ein interner Next.js-Fehler geworfen und die not-found.js-Komponente gerendert. Wenn diese jedoch innerhalb eines try/catch-Blocks verwendet wird, wird der Fehler abgefangen und verhindert das Rendern von 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)
  }
}

Sie können die unstable_rethrow-API verwenden, um den internen Fehler erneut zu werfen und das erwartete Verhalten fortzusetzen:

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

Die folgenden Next.js-APIs basieren auf dem Werfen eines Fehlers, der erneut geworfen und von Next.js selbst behandelt werden sollte:

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

Wenn ein Routensegment markiert ist, einen Fehler zu werfen, es sei denn, es ist statisch, wird ein dynamischer API-Aufruf ebenfalls einen Fehler werfen, der ähnlich nicht vom Entwickler abgefangen werden sollte. Beachten Sie, dass Partial Prerendering (PPR) dieses Verhalten ebenfalls beeinflusst. Diese APIs sind:

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

Hinweis:

• Diese Methode sollte am Anfang des Catch-Blocks aufgerufen werden, wobei der Fehler-Objekt als einziges Argument übergeben wird. Sie kann auch innerhalb eines .catch-Handlers einer Promise verwendet werden.
• Wenn Sie sicherstellen, dass Ihre Aufrufe von APIs, die Fehler werfen, nicht in einem try/catch eingewickelt sind, müssen Sie unstable_rethrow nicht verwenden.
• Jede Bereinigung von Ressourcen (wie das Löschen von Intervallen, Timern usw.) muss entweder vor dem Aufruf von unstable_rethrow oder innerhalb eines finally-Blocks erfolgen.