Exercise 3: Refusing on Delete, Traced Back to Chapter 2 — Possible Solution
====================================================================

WHY DELETING A PAGE WITH CHILDREN FAILS WITH A FRIENDLY ERROR
------------------------------
Per this chapter, the destroy() method wraps $page->delete() in a try/catch block. When a page still has children, the database itself refuses the deletion at the constraint level, throwing a QueryException from a foreign-key violation rather than allowing the row to be removed. Catching that exception and returning a plain, readable message - "Can't delete a page that still has children - move or delete them first" - turns that low-level database refusal into an expected, understandable outcome in the admin UI instead of letting a raw stack trace reach the user.

WHICH EARLIER CHAPTER'S DECISION THIS TRACES BACK TO
------------------------------
Per this chapter, this behavior is a direct consequence of Chapter 2's own decision to define the parent relationship with restrictOnDelete() rather than the framework's more dangerous cascadeOnDelete() default. That earlier choice is what makes the database refuse the deletion in the first place - this chapter's try/catch block doesn't invent the restriction, it only makes the database's own pre-existing refusal legible to whoever is using the admin interface.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the friendly error is produced by catching a QueryException raised when the database's own foreign-key constraint refuses the deletion, and correctly traces that constraint back to Chapter 2's own restrictOnDelete() decision rather than treating it as something newly introduced in this chapter.