Throw, Result, or neither?
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A deep dive into error handling strategies in event-sourced systems, arguing that returning business failures as domain events is often preferable to throwing exceptions or using Result types. Using a shopping cart example in TypeScript with the Emmett framework, the author demonstrates how events like ProductItemOutOfStock and ShoppingCartItemLimitReached can carry richer business data than exceptions or Result wrappers. The post covers selective persistence (deciding whether to append an event to the stream), batch command handling with atomic vs. non-atomic semantics, and Emmett's middleware helpers (rejectOn, skipOn, stopOn, stopAfter, throwOn) that let the same decision function behave differently across use cases like HTTP endpoints, cart imports, and saved-list restores. Exceptions are still used for invalid operations and infrastructure failures, while Result types are critiqued for adding propagation overhead without replacing the persistence and continuation decisions that event types already encode.
