Errors

Foundations covers the types: what an Option is against a Result, what ? does, what expect claims, what a panic costs. This section is the other half: what happens to a failure on its way out of your program — from the read that produced it, through the function that could not handle it, to the sentence a person reads and the number a shell script tests.

Four of these pages are finished; the other six are stubs — outlines waiting for a runnable example, written so the arc has a shape and a permanent URL before the prose exists. A page graduates by getting an examples/ program and losing its stub notice, which is the same promise as everywhere else here: no page claims something a program has not printed. The two crate pages at the bottom cannot graduate the usual way, because examples in this library build with no dependencies — see CONTRIBUTING.

Lesson	Level	What it teaches
Readers are fallible	201	Why a line arrives as io::Result<String> and not String — and what .flatten() quietly does to the failure
Endless iteration	201	End of input is Ok(0), not an error — so a loop that only watches for Err never stops
main can return a Result	201	? at the top level, the Debug form the runtime prints, and which exit code you get
Standard error, and exit status	101 → 201	Two streams and one number: what belongs on each, and what a caller can actually test
Keep going, or stop	201	One bad row is a design decision — collect::<Result<Vec<_>, _>>(), and the alternative that keeps both halves
unwrap is a TODO you forgot to remove	201	The three ways Rust panics, and why almost every unwrap you have arrived by paste from a crate's own front page — serde's README unwraps twice
What makes a type an error	201	std::error::Error asks for Debug, Display and one optional method — and source(), the optional one, is where hand-written errors go wrong
Not every error is an io::Error	201	Two error types in one function: erase the difference with Box<dyn Error>, or name it with an enum — and which one your caller needs
anyhow and context	201	Turning "No such file or directory" into an error that names the file it was reading
thiserror vs anyhow	301	A library names its errors and an application erases them — the same crate on the wrong side of that line is the mistake

Where this arc goes

The order is deliberate: the first two pages are about failures you did not notice, the middle three about failures that reach the user, and the last three about the type they travel in. That is roughly the order a real program acquires them — you write the happy path, discover it lies, then discover the lie was structural.

Po polsku

Największa pułapka jest tu terminologiczna, a nie techniczna. Polskie materiały o Javie, C# czy Pythonie mówią o obsłudze wyjątków — rzucaniu, łapaniu, bloku try/catch — i to jest pierwsza fraza, którą polski czytelnik wpisuje w wyszukiwarkę. W Ruscie nie ma jednak czego szukać pod tym hasłem: wyjątków nie ma w ogóle, błąd jest zwykłą wartością zwracaną (Result), a panic! to nie wyjątek, tylko przerwanie programu, którego nie łapie się dla kontroli przepływu. Dlatego ten dział nazywa się „obsługa błędów”, nie „obsługa wyjątków”, a po angielsku szuka się rust error handling, nigdy rust exceptions.

Drugie rozróżnienie jest tym, czym ta sekcja różni się od Foundations: tam poznajesz typy (Option, Result, ?), tutaj drogę błędu na zewnątrz programu — od odczytu, który go wyprodukował, przez funkcję, która nie umiała go obsłużyć, aż po zdanie czytane przez człowieka i liczbę testowaną przez skrypt powłoki. Dwa słowa z tego końca trasy zostają po angielsku, bo tak nazywa je system: stderr (strumień błędów, obok stdout) i exit status — kod wyjścia, w którym zero znaczy sukces, odwrotnie niż podpowiada intuicja z wartości logicznych, gdzie zero to fałsz. Skrypt powłoki nie czyta twojego komunikatu; czyta tę jedną liczbę.

Kolejność lekcji w tabeli nie jest przypadkowa i warto ją czytać po kolei: najpierw awarie, których w ogóle nie zauważyłeś, potem takie, które docierają do użytkownika, a na końcu typ, w którym błąd podróżuje. Mniej więcej w tej kolejności prawdziwy program je zdobywa — najpierw piszesz ścieżkę szczęśliwą, potem odkrywasz, że kłamie, a potem, że kłamstwo było strukturalne.

Szukaj po polsku: obsługa błędów w Ruscie · dlaczego Rust nie ma wyjątków · kod wyjścia programu · rust error handling · rust Result vs panic