Throw, Result, or Neither?
14 hours ago
- The author argues that business failures like out-of-stock or item limit should be returned as events rather than exceptions or Result types, allowing them to be queried and used in reports or workflows.
- Exceptions are reserved for invalid operations (e.g., adding to a confirmed cart) or infrastructure errors (e.g., unavailable event store), while Result adds little value beyond success/failure classification in most popular languages.
- Middleware like rejectOn, skipOn, stopOn, and stopAfter in Emmett allows flexible handling of events without persisting them, supporting different use cases (e.g., import rejection vs. saved-list restore).
- Event sourcing enables selective persistence: the decision returns events, but the application decides whether to append them, avoiding unnecessary data retention.