Exercise 3: Confirming the Friendly Delete-Refusal Message — Possible Solution
====================================================================

SETUP
------------------------------
A real parent page with at least one real child page is used - e.g.
"Programming" with "Web Development" as its child, matching Chapter 2's
own onDelete: Restrict constraint set up on the parentId relation.

ATTEMPTING THE DELETE
------------------------------
Calling deletePage(programmingPageId) per this chapter runs
prisma.page.delete({ where: { id: programmingPageId } }) inside a
try/catch block. Because "Web Development" still references
"Programming" via parentId, the database itself refuses the delete at
the foreign-key-constraint level (the same real database-level
enforcement verified back in Chapter 2's own Exercise 3) - Prisma
surfaces this as a PrismaClientKnownRequestError with code 'P2003'.

CONFIRMING THE FRIENDLY MESSAGE
------------------------------
The catch block's own instanceof and code === 'P2003' check matches,
so the function throws a new, friendly Error: "This page still has
child pages — move or delete them first." - not the raw Prisma
exception's own technical message, and not an unhandled crash. The
calling UI can display this message directly to the admin.

CONFIRMING THE PAGE WAS NOT DELETED
------------------------------
Querying "Programming" afterward confirms it still exists in the
database, unchanged - the delete genuinely never completed, rather than
partially succeeding before the error was thrown.

WHY THIS WORKS AS AN ANSWER
------------------------------
It uses a real parent-child pair that actually triggers the constraint
(not a childless page, which would just delete successfully and prove
nothing), confirms the specific friendly message text appears rather
than a generic "an error occurred," and separately verifies the row
itself survived the attempt - not just that an error was caught.