Journey through "unhappy path" - Dealing with exceptional conditions
summary
Avoid returning nulls and optional dependencies; prefer a special case object for absent domain entities and throw exceptions where business rules are violated. Create custom exception types organized under an Exception namespace, use a marker interface for component-level catches, and embed context via named constructors so messages are structured and data-accessible. Wrap third-party errors (example: Guzzle) into domain exceptions preserving the previous exception, centralize handling with Whoops and PSR-3 logging, and test exceptions consistently with arrange–act–assert.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:03Unhappy path
- 5:07Special case
- 9:43Create custom exception types
- 11:14Single responsibility principle
- 11:50Exception type
- 13:27Formatting exception messages
- 14:43Providing a context
- 15:35Exception wrapping
- 17:50Why so many exceptions
- 18:54Challenges
- 21:25Central Error Handler
- 22:21Whoops
- 27:57Test exception behavior
- 28:35Arrange act assert
- 29:54Feedback
related talks
38mLeveraging Typed Exceptions for Cleaner Error Handling
51mExceptions in PHP: more complicated than it appears
57mYou’re Doing Exceptions Wrong
06mException Driven Design
45mBeyond design patterns and principles - writing good OO code
57m“The Unexceptional Exceptions"
52mBreaking Bad Code: From simple problems to complicated solutions and back
25mAvoiding Disaster: Practical Strategies for Error Handling Slides
