A try/catch around a Next.js server action swallows the redirect it was meant to protect

JavaScript gives a function one way to leave without returning, and Next.js uses it. Calling `redirect('/dashboard')` throws. The thrown value travels up the stack until something catches it, and the framework's own machinery catches it higher in the rendering or request lifecycle and converts it into the navigation ^[1]. The dev.to post that walks through this says the throw is deliberate, not a bug ^[1]. The language does not mark it as privileged, so the nearest enclosing catch wins, whether it belongs to the framework or to you ^[2].

In the login action the post uses as its example, the whole body sits inside one try, so the catch logs "Login failed:" and returns `{ error: 'Something went wrong' }` after the credentials verified and the session cookie was written ^[3]. The collision comes from the framework putting a control-flow signal on the same channel the application's error handling owns ^[1][2]. Nothing in the wrapped version misuses try/catch. The post calls it code that "looks like exactly the kind of defensive coding you'd want" ^[14].

Notice which path fires. A bad password returns `{ error: 'Invalid credentials' }` from the `!user` check before `redirect()` is ever reached ^[6], so the failure path behaves as written. The swallow lands only on success: every correct login, none of the rejected ones ^[13]. A test that exercises the wrong-password branch will pass.

The console does not help either. The logged error carries a message or code from Next.js's internal redirect machinery rather than a shape a JavaScript developer recognises ^[5]. The post wrote that the "error" being caught is, ironically, "the successful outcome trying to happen" ^[12].

The fix the post prefers narrows the try to `verifyCredentials` and calls `redirect()` after the block, where its throw reaches Next.js cleanly ^[7]. I would default to that as well. Read the rewritten action before copying it: `setSessionCookie(user)` now sits outside the try, after the `!user` check ^[8]. A cookie write that throws propagates instead of returning the generic error object. If that call is genuinely risky, it needs a try of its own.

When the structure needs the broad try, the post's alternative catches everything and re-throws whenever `isRedirectError(error)` identifies the value as a redirect signal ^[9]. That guard imports from `next/dist/client/components/redirect`, a path into Next's compiled output ^[9]. The post calls the pattern more fragile because it depends on an internal Next.js utility instead of a stable public API, and recommends restructuring wherever the code allows ^[10].

`notFound()` throws through the same route ^[11]. Any Server Action, Server Component or route handler whose broad catch encloses either call is exposed to the same silent failure ^[11].