In Ruby, how do `catch`/`throw` differ from `raise`/`rescue`, and what happens when `throw` finds no matching `catch`?

## Two unwinding mechanisms Ruby has two ways to jump out of several nested calls at once, and they are easy to confuse because other languages spell exceptions `throw`/`catch`. - **`raise` / `rescue`** — exceptions. An `Exception` object is created, carries a message and a backtrace, and is matched by class in `rescue` clauses. It signals that something **went wrong**. - **`catch` / `throw`** — tagged non-local exit. There is no exception object when a matching `catch` exists; `throw` carries a tag and a value. It signals an **expected** change of control flow, such as "found it, stop searching". The language reference draws the same line: `throw`/`catch` are for expected non-local control flow, exceptions for exceptional situations. ## How `catch` and `throw` match ```ruby result = catch(:done) do walk_tree(root) # somewhere deep inside: throw :done, node :not_found end ``` The rules, from `Kernel#catch` and `Kernel#throw`: 1. `catch(tag)` runs its block and yields `tag` to it. Without an argument, `catch` creates a new unique object (as `Object.new`) and yields that, which guarantees no other code can throw to it by accident. 2. `throw(tag, value = nil)` looks for an active `catch` whose tag is the **same object** (same `object_id`). Equality is not enough: two separately built strings with the same text do not match. 3. When found, execution resumes at the end of that `catch`, and `catch` returns `value`. 4. If the block finishes without a matching `throw`, `catch` returns the block's last value. Symbols are the usual tag because the same symbol is always the same object. ## What happens on the way out As `throw` unwinds: - **`ensure` clauses run**, so files close and locks release as they would for an exception. - **`rescue` clauses do not intercept it**, not even `rescue Exception`, because no exception is being raised when a catch matches. - Frames between `throw` and `catch` simply stop; code after the call that led to `throw` does not run. ## When nothing matches If no active `catch` has the tag, `throw` raises **`UncaughtThrowError`** from the `throw` call: ```ruby begin throw :nope, 3 rescue UncaughtThrowError => e e.tag # => :nope e.value # => 3 e.message # => "uncaught throw :nope" end ``` `UncaughtThrowError` is a subclass of **`ArgumentError`**, and therefore of `StandardError`. Unlike a matched throw, it **is** an ordinary exception: a bare `rescue` or `rescue ArgumentError` between the `throw` and the top level will catch it. The design reasoning in the reference is that throwing a tag nobody expects is a programming error. ## Side-by-side | Aspect | `catch` / `throw` | `raise` / `rescue` | |---|---|---| | Intended for | expected early exit | errors | | Matched by | tag object identity | exception class (`===`) | | Payload | any value, returned by `catch` | an exception object | | Backtrace | none built when a catch matches | captured at `raise` | | `ensure` runs | yes | yes | | Intercepted by `rescue` | no (unless no catch matches) | yes | | Unmatched | `UncaughtThrowError` | unhandled, it ends the thread or program | ## A traversal example A parser that validates a deeply nested configuration can use `throw` to stop at the first fatal problem without threading a status value through every recursive call: ```ruby def check(node, path) throw :invalid, path if node.nil? node.each { |key, child| check(child, path + [key]) } if node.is_a?(Hash) end bad_path = catch(:invalid) { check(config, []); nil } ``` `bad_path` is `nil` when the whole tree is valid and the path to the first missing value otherwise. No exception object is created on the fast path, and any `ensure` inside the traversal still runs. If the problem were unexpected — a file that cannot be read — `raise` would be the right tool. ## Practical notes - Both are **methods on `Kernel`**, not keywords. Inside a `BasicObject` context, where `Kernel` is not included, call `::Kernel.catch` and `::Kernel.throw`. - Because a matched `throw` builds no exception object or backtrace, it avoids the cost that `raise` pays for them; that makes it suitable for frequent early exits, such as a parser that bails out of a deeply nested descent. - Do not use `throw` to report failures. Callers expect failures to arrive as exceptions they can `rescue` by class, with a backtrace to debug. - Prefer a `return` from a named method when the exit stays within one method; reach for `catch`/`throw` when it must cross method calls.