There is a bug

Sentry Simple Example 🚨

This example demonstrates how to record unhandled exceptions in your code with Sentry. There are several test pages below that result in various kinds of unhandled exceptions.

It also demonstrates the performance monitoring the SDK is able to do:

  1. A front-end transaction is recorded for each pageload or navigation.
  2. A backend transaction is recorded for each API or page route. (Note that currently only API routes are traced on Vercel.)
  3. Errors which occur during transactions are linked to those transactions in Sentry and can be found in the [trace navigator](https://docs.sentry.io/product/sentry-basics/tracing/trace-view/).
  4. Manual performance instrumentation is demonstrated in the final example below (throwing an error from an event handler).

Important: exceptions in development mode take a different path than in production. These tests should be run on a production build (i.e. 'next build'). Read more

  1. API route exceptions/transactions
    2. Note that 1 and 2 are not expected to work if deployed to Vercel yet.
    1. API has a top-of-module Promise that rejects, but its result is not awaited. Sentry should record Error('API Test 1'). Open in a new tab
    2. API has a top-of-module exception. Sentry should record Error('API Test 2'). Open in a new tab
    3. API has has an exception in its request handler. Sentry should record Error('API Test 3'). Open in a new tab
    4. API uses a try/catch to handle an exception and records it. Sentry should record Error('API Test 4'). Open in a new tab
  2. SSR exceptions/transactions
    3. Note that there are currently two known bugs with respect to SSR transactions: they don't get recorded on Vercel, and ones that are recorded and have an error are grouped in the Sentry UI by the error page name rather than the requested page name.
    1. getServerSideProps throws an Error. This should cause _error.js to render and record Error('SSR Test 1') in Sentry. Open in a new tab or Perform client side navigation
    2. getServerSideProps returns a Promise that rejects. This should cause _error.js to render and record Error('SSR Test 2') in Sentry. Open in a new tab
    3. getServerSideProps calls a Promise that rejects, but does not handle the rejection or await its result (returning synchronously). Sentry should record Error('SSR Test 3'), but will not when deployed to Vercel because the serverless function will already have exited. Open in a new tab
    4. getServerSideProps manually captures an exception from a try/catch. This should record Error('SSR Test 4') in Sentry. Open in a new tab
  3. Client exceptions
    1. There is a top-of-module Promise that rejects, but its result is not awaited. Sentry should record Error('Client Test 1'). Perform client side navigation or Open in a new tab
    2. There is a top-of-module exception. _error.js should render and record ReferenceError('process is not defined') in Sentry. Perform client side navigation or Open in a new tab
    3. There is an exception during React lifecycle that is caught by Next.js's React Error Boundary. In this case, when the component mounts. This should cause _error.js to render and record Error('Client Test 3') in Sentry. Perform client side navigation or Open in a new tab
    4. There is an unhandled Promise rejection during React lifecycle. In this case, when the component mounts. Sentry should record Error('Client Test 4'). Perform client side navigation or Open in a new tab
    5. An Error is thrown from an event handler. Sentry should record Error('Client Test 5'). (This page also demonstrates how to manually instrument your code for performance monitoring.) Perform client side navigation or Open in a new tab