Exercise 2: Typed Converter vs. Route Model Binding — Possible Solution
====================================================================

THE SCENARIO
------------------------------
A request arrives for /users/999999 -- a well-formed integer, but no
user with that ID actually exists in the database.

CHAPTER 2'S OWN <int:id> TYPED CONVERTER
------------------------------
The typed converter's own job stops at the regex level: it only
checks that the segment LOOKS like a valid integer (matches \d+) and
casts it to a real Python int before the view ever runs.

    pattern, types = compile_typed_pattern('/users/<int:id>')
    m = pattern.match('/users/999999')
    # matches successfully -- 999999 is genuinely all digits
    params = {k: types[k](v) for k, v in m.groupdict().items()}
    # {'id': 999999}  -- a real int, handed straight to the view

The view function receives id=999999 and reaches its own body
completely normally. Whether a row with that ID actually exists in
the database is never checked by the router at all -- that's left
entirely to whatever the view itself does next (typically a database
query that would then come back empty, requiring the view's own code
to handle that case explicitly).

LARAVEL'S REAL ROUTE MODEL BINDING
------------------------------
    Route::get('/users/{user}', function (User $user) {
        return $user->email;
    });

Per Laravel's own documentation, this doesn't just validate the SHAPE
of the segment -- it uses the type-hinted User class to actually query
the database for a matching row. For /users/999999, that query finds
no match. Laravel's own documented behavior for exactly this case:
"If a matching model instance is not found in the database, a 404
HTTP response will automatically be generated." The closure body
above -- $user->email -- is never even reached.

THE REAL DIFFERENCE, STATED DIRECTLY
------------------------------
Chapter 2's typed converter validates that a value is well-formed.
Laravel's route model binding validates that a value corresponds to
something real. A well-formed-but-nonexistent ID passes the first
check and fails the second -- which is exactly why /users/999999 reaches
a Django/Flask-style view with an untyped-but-typed converter (leaving
the "does this exist" check to the developer), while the identical
request against Laravel's own route model binding never reaches the
developer's own code at all.

WHY THIS WORKS AS AN ANSWER
----------------------------
It uses the exact concrete example from the prompt (/users/999999),
traces what each mechanism actually does with it using the chapter's
own real, previously-verified code and Laravel's own quoted
documentation, and states the real distinction precisely: validating
shape versus validating existence against real data.