Throw, Result, or neither?

A deep exploration of error handling strategies in event-sourced systems, comparing three approaches: throwing exceptions, returning Result types, and returning domain events. The author argues that business failures like out-of-stock or cart limit violations are better modeled as events rather than exceptions or Result wrappers, because they carry business data useful for projections, workflows, and reporting. The post introduces 'selective persistence' — where a decision always returns events but the application decides which ones to store — and demonstrates middleware patterns (skipOn, stopOn, rejectOn) in the Emmett framework for controlling persistence behavior. Batch import scenarios illustrate why throwing is inappropriate in async handlers, and why events enable richer recovery and continuation logic than exceptions allow.