Exercise 3: A Limitation There, an Advantage Here — Possible Solution
====================================================================

THE TWO-SIDED FINDING
------------------------------
Per this chapter, Chapter 2 identified dependent: :restrict_with_error as an application-level ActiveRecord check, a real limitation compared to Laravel's own database-level restrictOnDelete() constraint, since a raw SQL delete could bypass Rails' own check entirely in a way it could never bypass Laravel's. That same design choice pays a genuine ergonomic dividend in this chapter: because the check happens in application code rather than being enforced only by the database, destroy can simply return false and populate page.errors with a friendly message when it fails, all through ordinary ActiveRecord behavior.

WHY NO begin/rescue BLOCK IS NEEDED HERE
------------------------------
Per this chapter, Laravel's own Chapter 10 needed a try/catch around a raw QueryException specifically because its own delete guard lived one layer deeper, at the database - a failure there surfaces as a low-level database exception that has to be caught and translated into a readable message. Rails' guard never reaches the database in the first place when it fails; destroy simply returns false with page.errors already populated, so there's no exception to catch at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly restates Chapter 2's own finding as a real limitation, correctly explains why the same application-level design produces a genuine ergonomic advantage in this chapter, and correctly explains why no exception-handling block is needed here in contrast to Laravel's own try/catch requirement.