In Dart, what is the difference between Exception and Error, and when is catching an Error the wrong move?

## Two families, one throw Dart's core library splits thrown objects into two families, but the language treats them the same: both are thrown with `throw`, caught with `on`/`catch`, and neither is checked. The difference is **what the throw means**. | | `Error` | `Exception` | |---|---|---| | Meaning | a **bug**: the program did something it should have avoided | an **anticipated failure** a correct program can meet | | Who fixes it | the programmer, by changing code | the caller, by handling it at run time | | Expected to be caught? | no | yes | | Kind of type | a class you can extend | an `abstract interface class` you implement | | Stack trace | a subclass that **extends** `Error` records `stackTrace` on its first throw | none stored; read it from `catch (e, st)` | | Examples | `ArgumentError`, `RangeError`, `StateError`, `TypeError`, `UnsupportedError`, `AssertionError` | `FormatException`, `IOException`, `FileSystemException`, `TimeoutException` | The SDK's own documentation of `Exception` says being one "has no other effect than documentation". The distinction is a **contract with the reader**, not a runtime mechanism. ## How to tell which one a failure is The SDK's rule of thumb: if the condition is **detectable before the call** — the docs say the argument "must" or "must not" be something — violating it is an `Error`. `String.contains` documents that `startIndex` must not be negative, so a negative index throws a `RangeError`. If the condition **cannot be checked in advance** — the file vanished, the text is malformed, the server timed out — the callee reports it as an exception, effectively an alternative result the caller must handle. - `int.parse('x')` throws `FormatException`: the caller could not know the text was bad without trying. - `list[10]` on a three-element list throws an `IndexError`, which is a `RangeError`: the caller could check `length` first. - Reading a file that was deleted throws `FileSystemException`: nothing the caller checks beforehand can rule that out. ## Why catching an Error is usually wrong Effective Dart says **don't explicitly catch `Error` or types that implement it**, and the `avoid_catching_errors` lint enforces it. The reasons: 1. **It masks the bug.** An `Error` should unwind the stack and stop the program with a trace pointing at the mistake. A catch turns that into a program that keeps going in a state nobody designed. 2. **It swallows asserts.** A failed `assert` throws `AssertionError`; a catch that covers it makes the assertion vanish in debug runs, where it was meant to stop you. 3. **It catches system failures you cannot handle** — `StackOverflowError` and `OutOfMemoryError` are errors too. 4. **The fix is elsewhere.** Instead of adding a handler after the fact, go back and prevent the condition: check the length, use `int.tryParse`, validate arguments. The same logic is why Effective Dart says to **avoid catches without `on` clauses** (`avoid_catches_without_on_clauses`): a bare `catch (e)` catches every `Error` along with the exceptions you meant. ## Where a broad catch is legitimate - **Boundaries that isolate unrelated work** — framework or low-level code that runs arbitrary callbacks and must survive one failing. Even there, Effective Dart prefers catching `Exception` over catching everything, and insists you **do something** with what you caught: log it, show it or rethrow it. - **Tests of your own code**, which assert that a precondition violation throws the documented `ArgumentError` or `StateError`. What a Flutter app does with errors nobody caught — the framework's error hooks — is a separate subject owned by the Flutter errors topic. ## A quick diagnostic When a stack trace shows an `Error`, ask *which line broke a documented precondition?* When it shows an `Exception`, ask *which caller should have handled this, and did it have an `on` clause for it?* The first leads to a code fix, the second to a handler.