Exercise 3: Confirming the Try/Catch Handles a Real DB Exception — Possible Solution
====================================================================

STEP 1 — WITHOUT THE TRY/CATCH
------------------------------
export const DELETE: APIRoute = async ({ params }) => {
  await db.delete(pages).where(eq(pages.id, Number(params.id)));
  return new Response(JSON.stringify({ status: 'ok' }));
};

Calling this against a page that still has children causes Drizzle
to throw a real, raw database error (a MySQL foreign key constraint
violation, since onCascade: 'restrict' from Chapter 2 refuses the
operation at the database level). With no try/catch, this crashes
the request handler entirely, producing an unhandled 500-style error
with no readable message for whoever is using the admin interface.

STEP 2 — WITH THE CHAPTER'S OWN TRY/CATCH
------------------------------
export const DELETE: APIRoute = async ({ params }) => {
  try {
    await db.delete(pages).where(eq(pages.id, Number(params.id)));
    return new Response(JSON.stringify({ status: 'ok' }));
  } catch (err) {
    return new Response(
      JSON.stringify({ error: "Can't delete a page that still has children — move or delete them first." }),
      { status: 409 }
    );
  }
};

The identical delete attempt now returns a real 409 response with a
plain, readable error message instead of crashing - the database's
own low-level refusal is caught and translated into an expected,
understandable outcome.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly demonstrates the raw, unhandled failure without a
try/catch, and correctly shows the same operation producing a clean,
readable 409 response once the catch block is added - concrete proof
that this database-level constraint genuinely needs exception
handling, unlike Rails' own smoother, non-exception path.