Is `try { ... } finally { ... }` with no `catch` clause legal JavaScript, and what does that shape express that a full try/catch/finally does not?

## Three legal shapes A `try` statement must be followed by a `catch` clause, a `finally` clause, or both: ```js try { risky(); } catch (err) { handle(err); } // handle, no cleanup try { risky(); } finally { cleanup(); } // cleanup, no handling try { risky(); } catch (err) { handle(err); } finally { cleanup(); } ``` `try { risky(); }` on its own is a SyntaxError. The parser refuses a try block that promises nothing. ## What try/finally says The two-clause `try/finally` form encodes a specific and common situation: *this scope acquired something and must release it, but it does not know how to recover from failures here.* Releasing is a local responsibility; recovering is the caller's. ```js function withLock(lock, work) { lock.acquire(); try { return work(); } finally { lock.release(); } } ``` If `work()` throws, the lock is released and the error travels on to whoever called `withLock`. The function has done its whole job - it never pretended to understand the failure. This is the shape to reach for around spinners and loading flags, in-flight counters, temporary state you toggled, timers you started, and any handle you opened. ## Why catch-clean-rethrow is worse The usual alternative looks equivalent and is not: ```js try { return work(); } catch (err) { lock.release(); throw err; // easy to get subtly wrong } lock.release(); // and now the success path needs its own copy ``` Three problems. The cleanup is duplicated across the success and failure paths, so the two drift apart. The `catch` clause is now a place where somebody will later add logic that quietly absorbs the error. And a `return`, `break` or `continue` elsewhere in the try block skips the trailing cleanup entirely, while `finally` would have covered it. The `try/finally` version has one cleanup site that covers every exit. ## Optional catch binding When you *do* handle the error but never look at it, ES2019 lets you omit the binding: ```js function isValidJson(text) { try { JSON.parse(text); return true; } catch { return false; } } ``` Before ES2019 you had to write `catch (err)` and leave `err` unused, which linters then flagged. `catch { }` is not a different kind of catch - it still catches everything thrown, whatever the value - it simply declares that this handler does not need the value. Reach for it only when the *reason* really is irrelevant, as in a probe like the one above; using it to hide an error you should be logging is the classic misuse. ## Choosing between the shapes A quick decision procedure: - Can this scope actually do something useful about the failure - retry, fall back, translate it for its own caller? If yes, you want a `catch`. - Does this scope hold something that must be released regardless of outcome? If yes, you want a `finally`. - Both can be true, and then you write all three clauses. Neither being true means you should not be writing a try statement here at all. The answer people get wrong is the third bullet's inverse: adding a `catch` that only logs and rethrows. That is a `try/finally` with extra noise and an extra opportunity to swallow something. ## A note on newer syntax Explicit resource management - `using` declarations backed by a `Symbol.dispose` method, plus `DisposableStack` - is a recent addition to the language that automates the acquire/release pairing this pattern expresses by hand. Engine support is still arriving, so hand-written `try/finally` remains the portable way to express it and is what interviewers expect you to reach for.