In a Livewire component, what does the exception($e, $stopPropagation) hook do, and when would you use it instead of a try/catch?

## What the hook is The calls Livewire makes on your component, an **action** such as `placeOrder()`, a **lifecycle hook** such as `updatedQuantity()` or the `render()` method, go through a wrapper. If that call throws, the wrapper does not rethrow straight away. It creates a small closure, conventionally named **`$stopPropagation`**, and fires the `exception` hook with the exception and that closure. After the hook returns, the exception is rethrown **unless** the closure was called. ```php public function exception($e, $stopPropagation): void { if ($e instanceof OutOfStockException) { $this->addError('items', $e->getMessage()); $stopPropagation(); } } ``` ## What happens with and without stopping | In the hook | Result | |---|---| | `$stopPropagation()` called | exception swallowed; the request continues and the component renders | | not called | exception rethrown; Laravel's exception handling takes over | | hook not defined | same as not called | When propagation is stopped, the rest of the throwing method is still skipped, because the exception interrupted it. The request then moves on to the next step of the pipeline, so the view renders with whatever state existed at that point. ## How validation uses it Livewire's validation support is itself a component hook that implements the same `exception` method. When `$this->validate()` throws Laravel's `ValidationException`, that hook puts the validator's errors into the component's error bag and stops propagation. That is why a failed validation inside an action does not become an HTTP error: the action simply ends early and the form re-renders with messages. It also means validate() works as an early return inside an action. ## When to use it instead of try/catch - **One domain exception, many actions.** An order form might throw `OutOfStockException` from `addLine()`, `updatedItems()` and `placeOrder()`. One `exception()` method turns it into the same field error everywhere. - **Cross-cutting behaviour in a trait.** Traits can supply the hook with the trait-name suffix, so a shared trait can translate a family of exceptions for every component that uses it. - **Early exit.** Throwing a known exception from deep inside a helper and stopping it in `exception()` ends the action cleanly. Keep a local `try/catch` when only one action cares, when you need to recover and continue inside the same method, or when the handling differs per call site. ## Pitfalls 1. **Swallowing everything.** Calling `$stopPropagation()` unconditionally hides real bugs and database errors from logging and from the error page; always check the exception type first. 2. **Assuming state rolled back.** Any property written before the throw stays written; stopping propagation does not undo it. 3. **Expecting it to catch render errors from other components.** It applies to calls Livewire makes on this component. 4. **Calling it from the browser.** `exception` is on Livewire's protected method list, so a client cannot invoke it as an action. ## Where it fits among other error paths | Mechanism | Scope | |---|---| | `try/catch` in the action | one call site | | `exception()` on the component | every action, hook and `render()` call on that component | | trait-suffixed `exception` hook | every component using the trait | | Laravel's exception handler | anything that propagates out of the request | The component hook sits between the local and the global level. It is the right tool when the error is **expected** and belongs to this screen's user experience, such as an out-of-stock line on an order form. Errors that are not expected should keep flowing to Laravel's handler, where they are reported and logged; converting them into a friendly message inside a component hides them from whoever operates the application.