Validation and errors
Handle errors centrally
Use not-found and error handlers while preserving expected domain outcomes and useful operator context.
9 minute lesson
Missing bookmarks return a controlled response, while a storage exception reaches onError with a request id and safe body. That contrast gives us something useful to test instead of a rule to memorize.
A centralized error boundary handles unexpected failures; it should not turn every expected outcome into a generic server error. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
The happy path can hide a bad design: you can throw strings for normal branches or expose full exception details to the client and still get one successful demo. Push past the demo. model expected outcomes explicitly and reserve the central error boundary for unexpected failures, then test the condition most likely to prove the choice wrong.
The module is moving toward one outcome: Reject malformed or unauthorized requests at the boundary and keep domain code independent of raw request parsing. Save the before-and-after evidence now; it will make the final project review much more honest.
Trigger four failure classes and verify status, response shape, logs, and request-id correlation. Save the evidence, then explain which requirement would force you to choose a different design.
Lesson completed