Suppose a program divides 100 by a number entered at the keyboard. Entering zero raises ZeroDivisionError and interrupts normal execution. A rescue clause gives that exception somewhere to go: control jumps to the clause instead of continuing through the division. If division succeeds, Ruby skips the rescue clause. section 6.4.1 section 6.4.2
Handle the expected error
Wrap the division in `begin` and `end`, with `rescue ZeroDivisionError` after it. The rescue body can print an error message; successful division bypasses it. Naming the exception matters: a bare `rescue` handles descendants of StandardError and might hide an unrelated problem. section 6.4.2
Placement sets the boundary. A method body or `do`/`end` block can contain a rescue clause without an explicit `begin`: the clause governs preceding statements in that body or block. Add an explicit `begin`/`end` when only a smaller operation should be covered. For example, rescuing just `File.open` lets a method return on an open failure without treating later work as the same failure. section 6.4.2
Use `rescue ArgumentError => e` when the handler needs the exception object. `e.message` gives its message; `e.backtrace` gives the call stack recorded when it was raised. A bare `raise` inside the handler re-raises the exception, useful after recording information that should not suppress the failure. section 6.4.6
Rescue and `ensure` do different jobs. A rescue clause runs for an exception it handles; an ensure clause runs whether or not an exception occurs. A file-reading method can rescue an invalid-line error, re-raise it, and still close its file handle in `ensure`. If no existing exception name describes the failure, a class inheriting from StandardError can give it a specific name and a targeted rescue clause. section 6.4.7 section 6.4.8
