In a web framework's middleware chain, what happens when a hook throws instead of delegating to the next element?

A middleware chain is assembled by nesting, not by queueing. Each element is handed the request plus one callable representing **the entire rest of the chain**, and the innermost callable is the route handler. An element does some work, delegates, and regains control when the inner part finishes. Because delegation is an ordinary call, the chain is a call stack — and that single fact explains everything that happens when something throws. ## Two directions, not one Picture the chain as rings around the handler. A request travels inward through each ring, the handler runs, and the result travels back outward through the same rings in reverse. When a hook throws instead of delegating, the request stops travelling inward at that ring. - **The inward side is never entered.** The hooks that would have run after it, and the handler itself, are not called. Whatever they do — body parsing, argument binding, the business work — simply does not happen, and nothing there can catch up later. - **The outward side is already on the stack.** Every hook the request passed through to reach this one has an unfinished delegate call in its frame. The failure unwinds through those frames in the reverse of the order they were entered. Reverse order is the part candidates most often get backwards. The hook registered first is usually entered first, which makes it the **last** one the error passes through on the way out. The error stage, placed outermost precisely so that it wraps everything, is therefore the final stop rather than the first. ## Being on the stack is not the same as seeing the error An enclosing hook participates in the unwind, but that does not mean its code runs. What runs depends on how its code is written around the delegate call. | Code in the enclosing hook | Runs when the inner part throws? | Typical use | |---|---|---| | Plain statements after the delegate call | No — the unwind skips them | after-phase work that assumes success | | A cleanup construct wrapping the call | Yes, on both paths | releasing a connection, clearing ambient context | | A catch wrapping the call | Yes, and it decides what happens next | recording, enriching, translating, recovering | This is why a hook written as "record the start time, delegate, record the finish time" silently loses every failed request: the finish line lives on the success path only. ## Where the throw happened still matters From the client's side a failure looks similar wherever it came from, but the amount of work already done is very different. 1. **A hook throws before delegating.** Nothing inward ran. The handler never executed, so no business side effect can exist yet — only whatever that hook and its enclosers already did. 2. **The handler throws.** Every entered hook's before-phase ran and the handler ran partway, so side effects it already performed remain; the outbound half of the chain is lost. 3. **A hook throws after its delegate call returned.** The handler completed successfully and the failure is in the outbound work, leaving a state where the work is done but the caller is told it failed. Distinguishing these is what makes a failure diagnosable afterwards, which is why a good error stage records not only the error but which elements were entered. ## Frameworks differ in how the failure is represented Some frameworks propagate failures as thrown exceptions unwinding a real call stack; others model the chain over a value representing eventual completion, where the failure is carried in that value and the unwind is a composition of failure paths; a few use an explicit error-carrying return type that every element passes along. The vocabulary changes — a raise, a failed completion, an error branch — but the structural rule does not: the inward side that was never entered does nothing, and the outward side reacts only where it explicitly handles the failure path. The models do differ in one respect worth knowing: with thrown exceptions propagation is automatic, while with error-carrying values an element that forgets to pass the failure along can drop it silently. ## What to take into a review - Assume any hook may throw, and ask what the enclosing hooks have already acquired. - Put anything that must happen on both paths in a cleanup construct, never in the statements after the delegate call. - Never write code that assumes the handler ran just because the request reached the chain. - Remember that the outermost element is the last to see the failure, and design it to be the place that shapes the answer.