There is one question I keep getting about my event-sourced code: why don’t I use Result?
It usually comes after someone sees a decision throwing an exception. They would put the failure in a Result, leave try/catch at the application boundary, and make the distinction explicit in the return type. That is a fair question, but the return type is only part of the answer.
I don’t mind using exceptions. I also return business failures as events. Which one I choose depends on what the failure means and what the application needs to do with it. What’s more, I don’t mind Result either, as long as I’m using a language where it’s a native and idiomatic way to use it. Stil…
\nSome failures are worth retaining as business data. An out-of-stock request can contribute to an unmet-demand report. A declined payment can start another process or be grouped by its reason. An item limit can explain why customers abandon an operation.
\nGojko Adzic calls the systematic use of unexpected or marginal usage patterns to improve a product lizard optimization. Repeated out-of-stock requests can reveal demand we do not serve or a user experience that encourages impossible quantities. Turning every attempt into only a response or an exception log makes that pattern harder to find. An event gives the application data it can query, project, and use in another process.
\nEvent Sourcing can help take advantage of unwanted and unexpected failures. We can model negative outcomes as events, just like regular ones. Our business logic informs us of what happened, not whether it’s a success or an error. It’s just an outcome of our decision.
\nSo essentially we’re getting three options to deal with an unexpected scenario.
\nOutOfStockError) and catch it at the boundary;Result with the failure on its error track;ProductItemOutOfStock) and decide separately what we do with it.Having that, my answer is rarely “just throw” or “just return Result.” Before choosing either, I need to know what should be persisted, what the caller should receive, and whether the failure belongs in the application’s exception path.
Let’s say that the customer asked for a quantity we cannot supply. Recording that outcome can be useful even though the cart did not change. The cart may also reach its item limit or fail payment authorisation. These are expected business outcomes, and the decision can describe each one with a distinct event:
\nconst addProductItem = (\n command: AddProductItem,\n state: ShoppingCart,\n): ProductItemAdded | ProductItemOutOfStock | ShoppingCartItemLimitReached => {\n if (state.status === \"Confirmed\")\n throw new IllegalStateError(\n \"Cannot add a product to a confirmed shopping cart\",\n );\n\n const { shoppingCartId, productItem, availableQuantity, maximumItems, now } =\n command.data;\n\n if (productItem.quantity > availableQuantity)\n return {\n type: \"ProductItemOutOfStock\",\n data: {\n shoppingCartId,\n productId: productItem.productId,\n requestedQuantity: productItem.quantity,\n availableQuantity,\n attemptedAt: now,\n },\n };\n\n if (state.productItems.length >= maximumItems)\n return {\n type: \"ShoppingCartItemLimitReached\",\n data: {\n maximumItems,\n requestedProductId: productItem.productId,\n },\n };\n\n return {\n type: \"ProductItemAdded\",\n data: { shoppingCartId, productItem },\n };\n};ProductItemOutOfStock carries the requested and available quantities. ShoppingCartItemLimitReached carries the configured limit and the product that crossed it.
We could also model a single ProductItemAddingFailed event instead. It could have a reason string, but then we’d use the granularity and precision of the information. With distinct event types, a projection, workflow, endpoint, or test can check the relevant outcome directly.
What’s more, we could also add a FailedToAddProductToClosedShoppingCart and get rid of throwing entirely. We’ll get to that, but for now…
\nNot every failure needs a business event. A confirmed cart can no longer be modified, so AddProductItem is not a valid operation for that state. A command without required data is invalid as well. An unavailable event store, a stock-service timeout, or a serialisation error means the operation could not be completed reliably. I use exceptions for these cases.
The throw happens before an event is returned, so the handler has nothing to append. The exception retains its stack and reaches the application’s error boundary.
\nSome people prefer to use Result and hope for deterministic decision-making. Still, in most popular dev environments (TypeScript, Java, C#, Python, etc.), we can get exceptions. Even in strongly-typed Rust, we can get a panic or other cases. In the presented code loadShoppingCart can reject because of data unavailability, appendToStream can report a concurrency or connection error, and base code library code can throw on a random, stupid null pointer. The application still needs an error boundary somewhere:
try {\n const result = await handleAddProductItem(command);\n return mapResultToResponse(result);\n} catch (error) {\n return mapToErrorResponse(error);\n}That boundary might be inside WebAPI route, a message handler callback, or wrapped with a conventional error middleware. The remaining choice is whether expected business outcomes should use the same path.
\nResult would addResult puts the success value and the expected failures on separate branches, visible in the type like:
type Result<Success, Failure> =\n | { success: true; value: Success }\n | { success: false; error: Failure };The cart decision becomes:
\ntype AddProductItemFailure =\n | ProductItemOutOfStock\n | ShoppingCartItemLimitReached;\n\nconst addProductItem = (\n command: AddProductItem,\n state: ShoppingCart,\n): Result<ProductItemAdded, AddProductItemFailure> => {\n const { shoppingCartId, productItem, availableQuantity, maximumItems, now } =\n command.data;\n\n if (productItem.quantity > availableQuantity)\n return {\n success: false,\n error: {\n type: \"ProductItemOutOfStock\",\n data: {\n shoppingCartId,\n productId: productItem.productId,\n requestedQuantity: productItem.quantity,\n availableQuantity,\n attemptedAt: now,\n },\n },\n };\n\n if (state.productItems.length >= maximumItems)\n return {\n success: false,\n error: {\n type: \"ShoppingCartItemLimitReached\",\n data: {\n maximumItems,\n requestedProductId: productItem.productId,\n },\n },\n };\n\n return {\n success: true,\n value: {\n type: \"ProductItemAdded\",\n data: { shoppingCartId, productItem },\n },\n };\n};Technically it looks more or less the same: ProductItemAdded is returned on the success branch, while the other two errors are returned on the failure branch. The caller checks the branch before returning the event. In this application, adding the product changes the cart and produces a 204 response. Running out of stock or exceeding the limit leaves the cart unchanged and produces a 409 response. The handler appends only the success value:
const handleAddProductItem = async (\n command: AddProductItem,\n): Promise<Result<ProductItemAdded, AddProductItemFailure>> => {\n const state = await loadShoppingCart(command.data.shoppingCartId);\n const result = addProductItem(command, state);\n\n if (result.success) \n return PreconditionFailed();\n \n await eventStore.appendToStream(\n shoppingCartStreamName(command.data.shoppingCartId),\n [result.value],\n );\n\n return NoContent();\n};If we used event, it could look like that:
\nconst handleAddProductItem = async (\n command: AddProductItem,\n): Promise<Result<ProductItemAdded, AddProductItemFailure>> => {\n const state = await loadShoppingCart(command.data.shoppingCartId);\n const event = addProductItem(command, state);\n\n if (event.type === \"ProductItemOutOfStock\" || event.type === \"ShoppingCartItemLimitReached\") \n return PreconditionFailed();\n \n await eventStore.appendToStream(\n shoppingCartStreamName(command.data.shoppingCartId),\n [result.value],\n );\n\n return NoContent();\n};Both versions preserve the same three event types. Result adds a success-or-failure classification around them. Which can be fine, but if you look again at the sample, it’s still pretty easy to ignore the different consequences of the events. We’re just one check on success further from it.
I saw many codebases where people were just blindly muting all errors by default, getting no benefit from it, but just polluting the codebase. Also keeping in mind that they still need to wrap the codebase with try/catch and have a conventional mapping layer.
\nWe can also see that the Result wrapper in our case doesn’t add much besides success/error classification. If we’d like to return different response status based on the failure scenario, we’d need to add the same switch. So we’re not removing the decision; we’re just making it easier to ignore.
\nOf course, many languages made it streamlined by adding pipe operator etc. Yet, again, many popular environments don’t have it. TypeScript has no pipe operator; the TC39 proposal is not (yet?) part of the language. Repeating the branch adds checks throughout the call chain; introducing a helper library adds vocabulary that is not native to the language. Those libraries are extremely noisy and require tribal knowledge and onboarding.
\nScott Wlaschin, who popularised railway-oriented programming, makes the same qualification: Result models expected alternatives, but it is not intended to wrap every function or replace exceptions.
Same for events; we should always discuss with the business if this information is important for them and if they want to keep it. We should also ask what should happen and if we can and should recover in our business application when this scenario happens.
\nProductItemAdded, ProductItemOutOfStock, and ShoppingCartItemLimitReached just tell what has happened. Domain doesn’t need to care how the application handles it. It can mean failure for the current request and still be worth recording because a projection or workflow consumes it. Adding those rules to Result would move persistence concerns into the domain decision and add premature classification. When we change the behaviour in the application and record one of those scenarios, we would need to change domain code, even if business rules are the same. Just to formally move one case from failure to success.
Adding Result changes every calling layer without replacing the persistence rules, batch handling, or exception boundary. I do not see much of a gain here. Of course, a codebase that already uses Result as its error channel may judge it differently, especially when the alternatives are not events. Thus…
ProductItemOutOfStock might be needed after the request. Measuring unmet demand, suggesting alternatives, or showing failed attempts to support staff requires a durable event. Still, if our business doesn’t care about the fact and we just want to log it, or forward to the HTTP Response, then we may not need to record it. Appending it would retain data the application does not need. Omitting it from the decision would instead force the endpoint to reread the outcome.
For this example, the decision returns ProductItemOutOfStock to the caller and the stream remains unchanged. I call this selective persistence: the decision describes the outcome, while the application decides whether it should be durable.
Command Handling can be described by the following steps:
\nRead events from the stream and build the state from them (in other words aggregate stream).
\nRun the business logic using the command and the state. Use the default (initial) state if the stream does not exist.
\nAppend the result of the business logic (so events) at the end of the stream from which you’ve read events. Use the read version (or the one provided by the user) for an optimistic concurrency check.
\nIn a nutshell, we could generalise it as:
\nfunction handleCommand<State, Command, Event>(\n eventStore: EventStore, \n streamId: string,\n decide: (state: State) => Event[],\n evolve: (event: Event, state: State) => State,\n initialState: () => State,\n // 👇 See what I did here\n skipEvent?: (event: Event) => boolean\n ) {\n // 1. Get the state\n const { state, currentStreamVersion } = await eventStore.aggregateStream(streamName, {\n evolve,\n initialState,\n });\n\n // 2. Run business logic\n const events = decide(state);\n\n // 3. Filter out \"failure\" events \n const eventsToAppend = skipEvent ? events.filter(skipEvent) : events;\n \n // 4. Append events\n const appendResult = await eventStore.appendToStream(streamName, [event], {\n expectedStreamVersion: currentStreamVersion,\n });\n\n // 5. Return result\n return {\n ...appendResult,\n events, // 👈 all events\n appendedEvents, // 👈 only those that were appended\n newState: evolve(aggregation.state, event),\n }\n}A command handler reads a stream, rebuilds its state, runs a decision, applies the produced events, and appends them with an optimistic concurrency check. Emmett takes care of that flow. The application provides evolve to apply an event to state and initialState for a new stream.
We can pass skipEvent function that inspects the decision’s outcome before anything is appended. The decision still returns the same events; the function only changes how the handler treats them.
In Emmett, I allow it to encapsulate the Command Handler setup by:
\n// 1. Command handler setup\nconst handle = CommandHandler<ShoppingCart, ShoppingCartEvent>({\n evolve,\n initialState,\n middleware: [\n skipOn(\n (event) => event.type === \"ProductItemOutOfStock\" \n || event.type === \"ShoppingCartItemLimitReached\"\n ),\n ],\n});\n\n// 2. Usage\nconst result = handle(eventStore, shoppingCartId, addProductItem);I think that this setup clearly shows that we’re separating the business logic from how the business logic handles that, by explicitly using skipOn middleware, we’re telling that when such an event happens, we don’t want to store it, but we’ll still return it in the result.
This gives us the option to still do e.g. error mapping to HTTP status as:
\nimport {\n Conflict,\n NoContent,\n on,\n ResponseFromEvents,\n toWeakETag,\n} from \"@event-driven-io/emmett-expressjs\";\n\nconst addProductItemApi = (router: Router) =>\n router.post(\n \"/shopping-carts/:shoppingCartId/product-items\",\n on(async (request: AddProductItemRequest) => {\n const shoppingCartId = request.params.shoppingCartId;\n const productId = String(request.body.productId);\n const availableQuantity = await inventory.getAvailableQuantity(productId);\n\n const command = {\n type: \"AddProductItem\",\n data: {\n shoppingCartId,\n productItem: {\n productId,\n quantity: Number(request.body.quantity),\n },\n availableQuantity,\n maximumItems: shoppingCartPolicy.maximumItems,\n now: new Date(),\n },\n\n const { events, nextExpectedStreamVersion } = await handle(\n eventStore, \n shoppingCartId, \n (state) => addProductItem(state, command),\n );\n\n if(events.some(event => event.type !== \"ProductItemAdded\"))\n return PreconditionFailed();\n\n return NoContent({\n eTag: toWeakETag(result.nextExpectedStreamVersion),\n }),\n });We could, of course, do more advanced error or status mapping by returning exact data, etc. But this example proves that we’re not losing anything compared to the Result scenario. The code is still pretty simple, as with throwing, but more explicit and straightforward.
\nYou may be wondering why I added middleware, which sounds posh for simple filtering. But let’s discuss one more scenario: a batch import from the external e-commerce system.
\nA batch import often contains the contents of multiple shopping carts. Passing all of them to one command handler would be the wrong boundary here: each cart has its own stream and its own concurrency check.
\nEven a single imported shopping cart can still require several operations. Especially if we’re trying to deduce what has happened to a shopping cart in the external system, or we should add some specific operations on top (e.g., discounts, etc.).
\nThe common scenario for imports is translating state changes (e.g., products in the shopping cart) into commands. This gives at least a chance to make our domain context meaningful. Not perfect, but we’ve got to save ourselves sometimes.
\nAfter translation, we may end up with a sequence of granular business operations. The mapping could look like that:
\nconst importCartCommands: AddProductItem[] = importedCart.productItems.map(\n (productItem) => {\n type: \"AddProductItem\",\n data: {\n shoppingCartId: importedCart.shoppingCartId,\n productItem,\n availableQuantity: stockByProductId[productItem.productId],\n maximumItems,\n now,\n },\n }),\n);And feed it into our command handler:
\nconst { events, nextExpectedStreamVersion } = await handle(\n eventStore, \n shoppingCartId, \n importCartCommands.map(command => (state) => addProductItem(state, command)),\n);Every command uses the existing addProductItem decision and sees the provisional state produced by the previous accepted products. That allows us to apply our own rules and also handle idempotence correctly. Persistence waits until every command has been accepted.
After batch processing, we can gather the result events. What’s more, each operation should use the state with the applied event from the previous command. We store the result in the shopping carts as a single atomic batch once the last command has been handled.
\nTechnically it’s the same command logic, just wrapped with foreach, as we now have a sequence of decisions instead of the single one.
\nWhat should happen if we encounter unwanted scenarios? So e.g. ProductItemOutOfStock or ShoppingCartItemLimitReached? Should we stop processing or continue? Let me be a consultant for a moment: It depends! Fine, but on what? On your business logic.
In our case, we probably wouldn’t want to stop adding product items if one of them was out of stock. Tho, we may decide that there’s no point in processing it further if we already reached the items limit.
\nHow to do it? We’d need to define a mapping function with different possible outcomes.
\ntype MapDecision = <Event>(event: Event) => void | 'APPEND' | 'SKIP' | 'STOP' | 'REJECT';Where:
\nThe example could be defined for all shopping cart events not to need repeat it in all functions:
\nconst mapShoppingCartDecision = (event: ShoppingCartEvent) => {\n switch(event.type) {\n case \"ProductItemOutOfStock\":\n return \"SKIP\";\n case \"ShoppingCartItemLimitReached\":\n return \"STOP\";\n case \"ShoppingCartWasAlreadyConfirmed\":\n return \"REJECT\"; \n }\n}We could pass it to our command handler and decide what to do with our processing.
\nIn Emmett, I wrapped it as:
\nconst handle = CommandHandler<ShoppingCart, ShoppingCartEvent>({\n evolve,\n initialState,\n middleware: [\n skipOn(\n (event) => event.type === \"ProductItemOutOfStock\",\n ),\n stopOn(\n (event) => event.type === \"ShoppingCartItemLimitReached\"\n ),\n rejectOn(\n (event) => event.type === \"ShoppingCartWasAlreadyConfirmed\"\n ),\n ],\n});Still, as you see, we’re building on top of our business logic. It remains the same; we’re just handling persistence, statuses, etc.
\nReturned events show which command handling passed before the rejection and which event stopped the import. The importer can report that outcome against the source record and continue with the next cart, which has a different stream.
\nFor one product, rejecting meant leaving the stream unchanged. For an imported cart, it may also mean discarding the accepted events produced earlier for the same record.
\nIf every command is accepted, the handler appends their events together to that cart stream. If one decision returns ProductItemOutOfStock or ShoppingCartItemLimitReached, result.events contains the outcomes produced up to that point, the imported record makes no change to the cart, and later commands are not considered.
The import job can map those events to a record-level outcome. It can report the exact business issue to the source system and continue with the next cart:
\nconst validatedProductIds = result.events.flatMap((event) =>\n event.type === \"ProductItemAdded\" ? [event.data.productItem.productId] : [],\n);\n\nconst failure = result.events.find(\n (event) =>\n event.type === \"ProductItemOutOfStock\" ||\n event.type === \"ShoppingCartItemLimitReached\",\n);\n\nconst importOutcome = (() => {\n switch (failure?.type) {\n case \"ProductItemOutOfStock\":\n return {\n status: \"WaitingForStock\" as const,\n validatedProductIds,\n productId: failure.data.productId,\n requestedQuantity: failure.data.requestedQuantity,\n availableQuantity: failure.data.availableQuantity,\n };\n\n case \"ShoppingCartItemLimitReached\":\n return {\n status: \"Rejected\" as const,\n validatedProductIds,\n productId: failure.data.requestedProductId,\n maximumItems: failure.data.maximumItems,\n };\n\n default:\n return {\n status: \"Imported\" as const,\n importedProductIds: validatedProductIds,\n streamVersion: result.nextExpectedStreamVersion,\n };\n }\n})();\n\nawait importStatusStore.record(importedCart.externalId, importOutcome);\n\nswitch (importOutcome.status) {\n case \"Imported\":\n await salesChannel.confirmImport(\n importedCart.externalId,\n importOutcome.streamVersion,\n );\n break;\n\n case \"WaitingForStock\":\n await pendingImports.waitForStock(\n importedCart.externalId,\n importOutcome.productId,\n );\n break;\n\n case \"Rejected\":\n await salesChannel.rejectImport(importedCart.externalId, {\n productId: importOutcome.productId,\n maximumItems: importOutcome.maximumItems,\n });\n break;\n}A saved-list restore uses different rules. Available products return to the cart, unavailable ones are reported, and reaching the cart limit ends the restore. Products added before either outcome remain valid, so this operation is not atomic.
\nThe additions run in one call because every decision needs the cart state produced by the accepted products before it. Otherwise, each decision would evaluate the item limit against an outdated cart.
\nThe loop stages and applies available products. It returns an unavailable product without staging it and continues. It also returns the item-limit event without staging it, then stops because the cart cannot accept another distinct product
\nAnd here we’re getting back to the essential question.
\nIf we’re getting the request from our UI, we’re the authority, so throwing could be fine; we return the status information telling the computer says no. (Read more in How to validate business logic).
\nStill, should we throw on an import scenario? Who’s the authority here? What we’re doing is internalising decisions that someone else already made and is just informing us about, or telling us to do our job based on this information.
\nSo throwing is not a valid option here. The external system told us that its cart contains these products. That is true about the source system, but it does not mean our cart can accept them. The importer translates the external record into commands, and the returned events describe how our local model understood each products.
\nFor an accepted record, the ProductItemAdded events identify the imported products and the resulting stream version is recorded. If stock is missing, the importer records the checked products and the missing quantity. It can continue with other records, then rebuild this cart’s commands with current availability after an inventory update. Retrying the unchanged commands immediately would only reproduce the same outcome. If the cart exceeds its item limit, waiting for stock cannot help; the source record needs correcting, so the importer marks it as rejected.
Of course we could still throw if this operation is synchronous and we want to give quick feedback to the caller. Still, typically, we run batch operations as a background process; also, to have proper resilience, you already saw above how much integration could happen during such an import. Services we integrate with can be unavailable, have transient issues, time out, etc.
\nThose failures enter the import job’s retry or dead-letter policy because there is no reliable business outcome to report yet. The returned events let the application choose between continuing, waiting for a relevant business change, and rejecting one record. Exceptions would just stop processing and not allow recovery and continue with next steps (Read more in No, it can never happen!)
\nThere can be various error cases also on our side.
\nIf another request changes the cart before our append, Emmett handles the concurrency conflict by loading the stream again and rerunning the decisions against its new state. Decision middleware runs again as well.
\nAn out-of-stock import is not a concurrency conflict. The cart state did not become stale; the input said that only two items were available. Running the same command again still returns ProductItemOutOfStock. The importer waits for an inventory change and then builds a new command with the current availability.
A custom retry policy can inspect a completed attempt, but it runs after that attempt’s append phase. Retrying a result is safe only when nothing was appended, and useful only when state or input can change.
\nA decision and its middleware can therefore run several times during one handler call. Code that only reads the command and state can be rerun. Sending an email or charging a card inside that code would repeat the external effect. In these examples, required external data is fetched before invoking the handler and included in the command. Effects caused by appended events run later in processors, after persistence.
\nMiddleware could also be useful for authorisation, logging, and measurements. Some of that work belongs around each decision; some should run only once for the complete handler call. Its position relative to the retry boundary determines whether it sees aggregate state and whether a retry repeats it:
\nawait beforeAll(input);\n\nconst result = await retry(async () => {\n const state = await aggregate(streamName);\n\n for (const decision of decisions) {\n await runWithDecisionMiddleware(decision, state);\n }\n\n return appendSelectedEvents();\n});\n\nawait afterAll(result);\n\nreturn result;The callback before the retry boundary receives the complete input once. It can authorise the command batch without repeating that work after a concurrency conflict. State is not available yet because the stream has not been loaded.
\nMiddleware inside the boundary receives each decision, and the state is rebuilt for the current attempt. A concurrency retry runs it again.
\nThe callback after the boundary receives the final result once, after persistence. It can record measurements based on appended events or the new stream version. If it throws, already appended events remain committed. Validation belongs earlier; notifications that must be delivered need a durable handler or outbox.
\nAs you see, message processing can end up being pretty complex. That’s also why we use Event-Driven Architecture, as it helps to make that explicit and reason about it.
\nThe import we discussed could be (and probably should be) triggered by an event (e.g. through a webhook), as we’re informed that those items were already processed and we should just accept or ignore it. What has been seen cannot be unseen.
\nWhether throwing is safe depends on what sits above the code to catch it. As discussed, a command handler behind an HTTP endpoint, its usual home, has the request: a thrown error unwinds into a response.
\nAsynchronous handlers, the projections, reactors, and workflows that react to events, have nothing above them. A throw propagates up, stops the processor, and leaves later events unhandled. The endpoint is only the usual home, not a rule: a command handler run from a reactor loses the same safety net. Instead of throwing, we need to turn the problem into data, so return an event.
\nA message handler can turn a declined shopping cart operation into a compensating workflow. For instance, for ProductItemOutOfStock order more products from the producer. It can, of course, just skip a message that should not block processing, or stop without advancing further.
The same for read models. A projection cannot prevent the source event from being recorded because that event is already in the stream. Throwing only prevents the read model from advancing. If an event carries a value the read model did not expect, throwing does not undo it. The check that should have stopped it belongs in the business logic, before the event was ever recorded; by the time the projection runs, it is too late.
\nIt builds a read model from events that are already recorded, and a recorded event is a fact: the projection only interprets it, so it has nothing to reject. If an event carries a value the read model did not expect, throwing does not undo it. The check that should have stopped it belongs in the business logic, before the event was ever recorded; by the time the projection runs, it is too late.
\nSo accept the event and build the best read model you can from it. Skip a duplicate, fall back to a default, clamp a value back into range, whatever keeps the read model sensible and moving. Its error handling must account for delivery and recovery rather than reuse the rules of a command decision.
\nThe decision returns ProductItemAdded, ProductItemOutOfStock, or ShoppingCartItemLimitReached because the application needs to know which one happened. Out of stock is an unfavourable outcome, but that alone says nothing about storage. During an import it cancels the current source record. During a saved-list restore it is skipped while earlier additions remain. At the HTTP endpoint it becomes a conflict response. The event stays the same; its handling depends on the use case.
I do not try to remove exceptions from this design. Adding a product to a confirmed cart is an invalid operation. An unavailable event store prevents the handler from producing a reliable result. Both go to the application’s error boundary.
\nResult could label some of the returned events as failures, but persistence, continuation, and retry still need their own decisions. The exception path remains as well. The event types already distinguish the business outcomes, so I prefer to leave them as they are.
So when someone asks me whether they should throw an error or use a Result type, I sometimes tell: actually, you can do neither.
Cheers!
\nOskar
\np.s. if you liked this one, check also:
\np.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.
","excerpt":"There is one question I keep getting about my event-sourced code: why don’t I use ? It usually comes after someone sees a decision throwing…","fields":{"slug":"/throw-result-or-neither/","prefix":"2026-07-20","langKey":"pl"},"frontmatter":{"title":"Throw, Result, or neither?","author":"oskar dudycz","category":"Event Sourcing","disqusId":null,"useDefaultLangCanonical":true,"cover":{"childImageSharp":{"resize":{"src":"/static/5eca6803bd7de5fa9ebc4a238f9b0745/4fe8c/2026-07-20-cover.jpg"}}}}},"authornote":{"id":"295c4649-a20b-5147-9ca5-5cb77fbcfe66","html":"Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/throw-result-or-neither/","lang":"pl","langKey":"pl","prev":{"id":"c573de20-1e46-5771-8132-39db8b3b0935","fields":{"slug":"/on-swimming-learning-and-my-journey/","prefix":"2026-07-13","source":"posts","langKey":"pl"},"frontmatter":{"title":"On swimming, learning and my journey to being the last one","category":"Motivational BS"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}