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

STEP 1 — WITHOUT THE TRY/CATCH
------------------------------
app.delete('/api/pages/:id', requireAuth, async (req, res) => {
  await pool.query('DELETE FROM pages WHERE id = ?', [req.params.id]);
  res.json({ status: 'ok' });
});

Calling this against a page that still has children causes mysql2 to
throw a real database error (a MySQL foreign key constraint
violation, since ON DELETE RESTRICT from Chapter 2 refuses the
operation at the database level). With no try/catch, this crashes
the request handler, producing an unhandled server error with no
readable message for the admin interface.

STEP 2 — WITH THE CHAPTER'S OWN TRY/CATCH
------------------------------
app.delete('/api/pages/:id', requireAuth, async (req, res) => {
  try {
    await pool.query('DELETE FROM pages WHERE id = ?', [req.params.id]);
    res.json({ status: 'ok' });
  } catch (err) {
    res.status(409).json({ error: "Can't delete a page that still has children — move or delete them first." });
  }
});

The identical delete attempt now returns a real 409 response with a
plain, readable error message instead of crashing.

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
409 response once the catch block is added - concrete proof that this
database-level constraint genuinely needs exception handling, the
same ceremony Laravel and Astro both required, unlike Rails' own
smoother, non-exception path.