Panicking: `panic!` vs Recoverable Errors

20 min read

In TypeScript and JavaScript, throw is your one tool for “something went wrong” — whether it’s a missing file, bad user input, or a genuine bug. Rust deliberately splits these into two categories: recoverable errors (modeled with Result<T, E>) and unrecoverable errors (signalled with panic!). Knowing which is which — and why Rust draws the line — is the heart of writing idiomatic, robust Rust.

Quick Overview

A panic is Rust’s way of saying “this should never happen; the program is in a state I cannot safely continue from.” Reaching one unwinds the current thread (running destructors as it goes) and, by default, terminates the program. Unlike a JavaScript throw, a panic is not the normal way to report expected failures — those belong in a Result. Use panic! for bugs and broken invariants, and use Result for anything a caller could reasonably handle.

Note: This page focuses on panic!, unwinding vs. aborting, and when panicking is appropriate. The recoverable side — Result<T, E> and Option<T> — is covered in result-option.md, and the unwrap/expect shortcuts that deliberately turn an Err into a panic live in unwrap-expect.md.

TypeScript/JavaScript Example

In JavaScript there is exactly one mechanism for signalling failure: throw. The same keyword reports user-input problems and programmer bugs, and a single try/catch can swallow both.

1
// JavaScript/TypeScript: `throw` is used for EVERYTHING.
2

3
// (1) Expected, recoverable failure — bad user input.
4
function parsePort(raw: string): number {
5
  const port = Number(raw);
6
  if (!Number.isInteger(port) || port < 0 || port > 65535) {
7
    throw new Error(`invalid port: ${raw}`);
8
  }
9
  return port;
10
}
11

12
// (2) A genuine bug / broken invariant — should "never" happen.
13
function applyDiscount(price: number, percent: number): number {
14
  if (percent < 0 || percent > 100) {
15
    throw new Error(`percent must be 0..100, got ${percent}`);
16
  }
17
  return price - (price * percent) / 100;
18
}
19

20
// Both kinds of failure are caught the same way:
21
try {
22
  const port = parsePort(process.argv[2] ?? "");
23
  console.log(`listening on ${port}`);
24
} catch (err) {
25
  // A bad CLI argument and an internal bug land in the same handler.
26
  console.error("startup failed:", (err as Error).message);
27
  process.exit(1);
28
}

Because throw and catch are untyped and uniform, nothing in the signature of parsePort or applyDiscount tells you whether a call can fail, what it fails with, or whether the failure represents recoverable user error or an internal bug.

Rust Equivalent

Rust splits the two cases apart. Recoverable failure is a value (Result); an unrecoverable bug is a panic!.

1
// Rust: two distinct mechanisms.
2

3
// (1) Recoverable failure -> the type system forces the caller to deal with it.
4
fn parse_port(raw: &str) -> Result<u16, std::num::ParseIntError> {
5
    raw.trim().parse::<u16>()
6
}
7

8
// (2) Broken invariant / bug -> panic. `assert!` panics with a message
9
//     when its condition is false.
10
fn apply_discount(price: u32, percent: u32) -> u32 {
11
    assert!(percent <= 100, "percent must be 0..=100, got {percent}");
12
    price - (price * percent / 100)
13
}
14

15
fn main() {
16
    // The Result must be handled — you cannot ignore it by accident.
17
    match parse_port("8080") {
18
        Ok(p) => println!("port = {p}"),
19
        Err(e) => println!("bad port: {e}"),
20
    }
21
    match parse_port("not-a-number") {
22
        Ok(p) => println!("port = {p}"),
23
        Err(e) => println!("bad port: {e}"),
24
    }
25

26
    println!("discounted = {}", apply_discount(200, 25));
27
}

Real output:

1
port = 8080
2
bad port: invalid digit found in string
3
discounted = 150

The signature -> Result<u16, ParseIntError> is a promise in the type: this call can fail, and here is the error type. By contrast, apply_discount returns a plain u32 — its signature says “this always succeeds” — and the only way it doesn’t is if a caller violates the documented contract, which is a bug worth crashing on.

Detailed Explanation

What `panic!` actually does

panic!("message") is a macro (note the !, like println!). When executed it:

Prints the panic message and source location to stderr.
Optionally captures a backtrace (controlled by the RUST_BACKTRACE environment variable).
Unwinds the current thread by default — walking back up the call stack and running each value’s destructor (Drop) so resources like files, locks, and heap allocations are released.
If the panicking thread is the main thread (and nothing catches the unwind), the process exits with a non-zero status.

1
fn main() {
2
    println!("about to panic");
3
    panic!("something went terribly wrong");
4
}

Real output (default debug build):

1
about to panic
2

3
thread 'main' panicked at src/main.rs:3:5:
4
something went terribly wrong
5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The process exits with status code 101 (Rust’s conventional exit code for an unwinding panic). Compare this with a JavaScript uncaught exception, which prints a stack trace and exits with code 1.

Backtraces are opt-in

Notice the line note: run with RUST_BACKTRACE=1 .... Unlike a Node.js exception, which always prints a full stack trace, Rust omits the backtrace by default for speed and noise reduction. Set the environment variable to see it:

1
fn main() {
2
    let v = vec![1, 2, 3];
3
    println!("trying to access index 10");
4
    let _x = v[10]; // out-of-bounds index -> panic
5
    println!("unreachable");
6
}

Run with RUST_BACKTRACE=1 cargo run:

1
trying to access index 10
2

3
thread 'main' panicked at src/main.rs:4:15:
4
index out of bounds: the len is 3 but the index is 10
5
stack backtrace:
6
   0: __rustc::rust_begin_unwind
7
             at /rustc/.../library/std/src/panicking.rs:697:5
8
   1: core::panicking::panic_fmt
9
             at /rustc/.../library/core/src/panicking.rs:75:14
10
   2: core::panicking::panic_bounds_check
11
             at /rustc/.../library/core/src/panicking.rs:280:5
12
   ...
13
   6: probe::main
14
             at ./src/main.rs:4:15
15
   7: core::ops::function::FnOnce::call_once
16
             at /rustc/.../library/core/src/ops/function.rs:253:5
17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Indexing out of bounds is one of several library operations that panic on a broken precondition. RUST_BACKTRACE=full shows every frame including std internals.

Tip: Many bugs in Rust manifest as a panic from a library function (index out of bounds, called Option::unwrap() on a None value, attempt to divide by zero). When you hit one, set RUST_BACKTRACE=1 to find the exact line in your code that triggered it.

Unwinding runs your destructors

By default a panic unwinds, and unwinding is not a silent crash — every value on the stack is dropped in reverse order, so cleanup code runs. Rust has no finally; the Drop trait fills that role.

1
struct Guard;
2

3
impl Drop for Guard {
4
    fn drop(&mut self) {
5
        println!("Guard::drop ran during unwinding (cleanup happened)");
6
    }
7
}
8

9
fn risky() {
10
    let _g = Guard;
11
    panic!("boom in risky()");
12
}
13

14
fn main() {
15
    let result = std::panic::catch_unwind(|| {
16
        risky();
17
    });
18

19
    match result {
20
        Ok(_) => println!("no panic"),
21
        Err(_) => println!("caught a panic, main continues"),
22
    }
23

24
    println!("main finished normally");
25
}

Real output:

1
thread 'main' panicked at src/main.rs:11:5:
2
boom in risky()
3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
4
Guard::drop ran during unwinding (cleanup happened)
5
caught a panic, main continues
6
main finished normally

Two things to take away. First, Guard::drop ran during the unwind — your cleanup is honored. Second, std::panic::catch_unwind can intercept an unwinding panic and turn it into a Result. That looks like try/catch, but it is emphatically not how you handle ordinary errors (see Pitfalls). It exists for narrow cases: stopping a panic from crossing a thread or a foreign-function-interface (FFI) boundary, and in test harnesses.

A panic kills the thread, not necessarily the program

If a spawned thread panics, only that thread dies. The panic is stored in the thread’s JoinHandle and surfaces as an Err when you join it.

1
use std::thread;
2

3
fn main() {
4
    let handle = thread::spawn(|| {
5
        panic!("worker thread blew up");
6
    });
7

8
    let result = handle.join();
9
    match result {
10
        Ok(()) => println!("worker finished cleanly"),
11
        Err(_) => println!("worker panicked, but main is still alive"),
12
    }
13

14
    println!("main thread keeps running");
15
}

Real output:

1
thread '<unnamed>' panicked at src/main.rs:5:9:
2
worker thread blew up
3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
4
worker panicked, but main is still alive
5
main thread keeps running

This is closer to how an unhandled rejection in one async task behaves than to a process-wide crash — but it only applies to additional threads. A panic on the main thread that nobody catches ends the program.

Key Differences

Two failure mechanisms, not one

Concept	TypeScript/JavaScript	Rust
Expected/recoverable failure	`throw` + `try/catch`	`Result<T, E>` value (see result-option.md)
Bug / impossible state	`throw` (same as above)	`panic!` / `assert!` / `unreachable!`
Shows up in the signature?	No (untyped)	Yes — `Result` is in the return type; panics are not
Default cleanup	`finally` blocks	`Drop` destructors run during unwind
Catching	`try/catch` (idiomatic, everywhere)	`catch_unwind` (rare, boundary-only)
Process exit code	`1` for uncaught exception	`101` for unwinding panic, `134` (`SIGABRT`) for abort

Unwinding vs. aborting

A panic can be handled by the runtime in one of two panic strategies:

unwind (the default): walk the stack, run destructors, optionally let catch_unwind stop the unwind. Slightly larger binaries (they carry unwinding tables) and a little runtime cost, but cleanup is guaranteed.
abort: immediately terminate the process via the platform’s abort (SIGABRT). No destructors run, no catch_unwind, smaller binaries. Common for embedded targets, some release builds, and anywhere you want a panic to be a hard, fast stop.

You select abort per build profile in Cargo.toml:

1
# Cargo.toml — abort instead of unwinding on panic
2
[profile.release]
3
panic = "abort"

Here is the difference made concrete. Under panic = "abort", the destructor does not run:

1
struct Guard;
2

3
impl Drop for Guard {
4
    fn drop(&mut self) {
5
        println!("this should NOT print under panic=abort");
6
    }
7
}
8

9
fn main() {
10
    let _g = Guard;
11
    println!("about to panic with abort strategy");
12
    panic!("aborting now");
13
}

Real output with panic = "abort":

1
about to panic with abort strategy
2

3
thread 'main' panicked at src/main.rs:12:5:
4
aborting now
5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The Guard::drop line never prints, and the process exits with code 134 (128 + signal 6, SIGABRT) instead of the 101 you get when unwinding. JavaScript has no equivalent toggle: an uncaught exception always unwinds the JS call stack and runs finally blocks.

	`unwind` (default)	`abort`
Runs `Drop` destructors	Yes	No
`catch_unwind` can intercept	Yes	No
Binary size	Larger (unwind tables)	Smaller
Exit on uncaught main-thread panic	code `101`	`SIGABRT` (code `134` on Unix)
Typical use	apps, libraries, tests	embedded, size-/speed-critical release builds

Note: Even with the default unwind strategy, a second panic that occurs while already unwinding (for example, a Drop impl that itself panics) escalates straight to an abort. Keep destructors panic-free.

Common Pitfalls

Pitfall 1: Treating `panic!` like JavaScript `throw`

The single most common mistake is reaching for panic! (or unwrap/expect) to report an expected failure such as bad input, a missing file, or a failed network call. That is what Result is for. Panicking on recoverable conditions makes your library unusable as a dependency — callers cannot recover, and the panic crashes their program.

1
// Anti-pattern: panicking on ordinary, recoverable input failure.
2
fn parse_port(raw: &str) -> u16 {
3
    raw.parse().expect("invalid port") // crashes the whole program on bad input
4
}
5

6
// Idiomatic: return a Result and let the caller decide.
7
fn parse_port_ok(raw: &str) -> Result<u16, std::num::ParseIntError> {
8
    raw.parse()
9
}

Both compile. The first is a design bug: a parsing routine should never decide to terminate the process. See unwrap-expect.md for the (narrow) cases where expect is justified.

Pitfall 2: Using `catch_unwind` as a general `try/catch`

std::panic::catch_unwind superficially resembles try/catch, so newcomers try to use it to handle ordinary errors. Resist. It is meant for boundaries (don’t let a panic unwind across an FFI call or take down a thread pool), not for control flow. It also requires the captured data to be UnwindSafe, and many ordinary types are not — so it often won’t even compile:

1
use std::cell::RefCell;
2
use std::panic;
3

4
fn main() {
5
    let shared = RefCell::new(0);
6
    // does not compile (error E0277: RefCell is not UnwindSafe)
7
    let result = panic::catch_unwind(|| {
8
        *shared.borrow_mut() += 1;
9
    });
10
    println!("{result:?}");
11
}

The real compiler error:

1
error[E0277]: the type `UnsafeCell<i32>` may contain interior mutability and a
2
reference may not be safely transferrable across a catch_unwind boundary
3
   --> src/main.rs:7:38
4
    |
5
  7 |       let result = panic::catch_unwind(|| {
6
    |  __________________-------------------_^
7
    | |                  required by a bound introduced by this call
8
  8 | |         *shared.borrow_mut() += 1;
9
  9 | |     });
10
    | |_____^ `UnsafeCell<i32>` may contain interior mutability and a reference may
11
    |         not be safely transferrable across a catch_unwind boundary
12
    = help: within `RefCell<i32>`, the trait `RefUnwindSafe` is not implemented

The UnwindSafe bound is the compiler steering you away from using panics for flow control: catching a panic mid-mutation could leave a value in a logically broken state. If you find yourself reaching for catch_unwind in business logic, you almost certainly want Result instead.

Pitfall 3: Assuming `abort` still runs cleanup

If you set panic = "abort" for the performance and binary-size benefits, remember that destructors do not run on panic. Code that relies on Drop for critical cleanup on the panic path (flushing a buffer, releasing an OS resource) will silently skip it. With unwind, that same cleanup runs.

Pitfall 4: Expecting a panic to print a stack trace by default

Coming from Node.js, you may expect every crash to dump a stack trace. Rust does not, for performance reasons — you only get the message and source location unless RUST_BACKTRACE=1 (or full) is set. In production, set it via the environment of your service so crash logs are actionable.

Pitfall 5: Forgetting that a panicked thread does not stop `main`

A panic in a spawned thread is captured in its JoinHandle and does not propagate automatically. If you spawn work and never join (or never check the result), a worker can die silently while the rest of the program carries on as though nothing happened. Always inspect handle.join() when a thread’s success matters.

Best Practices

Default to Result. If a caller could plausibly want to recover — bad input, a missing file, a timeout, a failed parse — return a Result. Reserve panics for situations that genuinely indicate a bug. The companion pages result-option.md and question-mark.md show how to make Result ergonomic with the ? operator.
Panic on broken invariants, not on user input. A function that receives an argument violating its documented contract (an index past the end of an array, a probability outside 0.0..=1.0) is entitled to panic — the caller has a bug. Use assert!, assert_eq!, and debug_assert! to express these checks. Document them under a # Panics heading in the doc comment.
Write good panic messages. A panic should explain what invariant was violated and ideally what value broke it. assert!(percent <= 100, "percent must be 0..=100, got {percent}") is far more useful in a crash log than a bare assert!(percent <= 100).

Use the right “this should never happen” macro. Rust ships several:

Macro	Meaning	Panics when reached?
`panic!("msg")`	Explicit, unconditional crash	Always
`assert!(cond, "msg")`	Crash if `cond` is false	Conditionally
`unreachable!()`	”Control flow can never get here”	Always (if it does)
`todo!()`	Placeholder for unwritten code	Always
`unimplemented!()`	Intentionally not implemented	Always

todo! and unimplemented! satisfy the type checker (they return !, the never type) so you can stub a function and keep compiling:

1
fn serialize(_d: &Direction) -> String {
2
    todo!("serialization not implemented yet")
3
}

Reaching it panics with not yet implemented: serialization not implemented yet. We cover the never type and the type-level reasoning in ../09-generics-traits/README.md.

Choose your panic strategy deliberately. Keep the default unwind for servers and libraries where graceful teardown matters; consider panic = "abort" for embedded targets or when you want the smallest, fastest binary and a panic is always fatal anyway.
Test the panic paths. Use #[should_panic(expected = "...")] to assert that a function panics on a contract violation, so the behavior is locked in:
```
1
#[test]
2
#[should_panic(expected = "whole must be non-zero")]
3
fn panics_on_zero_whole() {
4
    percentage(1, 0);
5
}
```
See ../13-testing/README.md for the full testing story.

Real-World Example

A production service typically faces both kinds of failure during startup. User-supplied configuration is recoverable — report it and let the operator fix it. An internal helper called with a logically impossible argument represents a bug and should panic loudly. Here is a config loader that draws that line clearly.

1
use std::collections::HashMap;
2

3
/// A recoverable error: the operator can fix bad config and retry.
4
#[derive(Debug)]
5
enum ConfigError {
6
    MissingKey(String),
7
    InvalidNumber { key: String, value: String },
8
}
9

10
impl std::fmt::Display for ConfigError {
11
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
12
        match self {
13
            ConfigError::MissingKey(k) => write!(f, "missing required key: {k}"),
14
            ConfigError::InvalidNumber { key, value } => {
15
                write!(f, "key `{key}` has invalid number: {value:?}")
16
            }
17
        }
18
    }
19
}
20

21
struct Config {
22
    port: u16,
23
    workers: u32,
24
}
25

26
/// Parsing operator-supplied config is RECOVERABLE -> return a Result.
27
fn load_config(raw: &HashMap<&str, &str>) -> Result<Config, ConfigError> {
28
    let port_str = raw
29
        .get("port")
30
        .ok_or_else(|| ConfigError::MissingKey("port".into()))?;
31
    let port = port_str
32
        .parse::<u16>()
33
        .map_err(|_| ConfigError::InvalidNumber {
34
            key: "port".into(),
35
            value: (*port_str).to_string(),
36
        })?;
37

38
    let workers_str = raw.get("workers").copied().unwrap_or("4");
39
    let workers = workers_str
40
        .parse::<u32>()
41
        .map_err(|_| ConfigError::InvalidNumber {
42
            key: "workers".into(),
43
            value: workers_str.to_string(),
44
        })?;
45

46
    Ok(Config { port, workers })
47
}
48

49
/// Splits `total_jobs` evenly across `workers`. A zero worker count is a
50
/// PROGRAMMER bug at this layer (the config layer guarantees >= 1), so we
51
/// treat it as unrecoverable.
52
///
53
/// # Panics
54
/// Panics if `workers` is zero.
55
fn chunk_size(total_jobs: u32, workers: u32) -> u32 {
56
    assert!(workers > 0, "worker pool must have at least one worker");
57
    total_jobs.div_ceil(workers)
58
}
59

60
fn main() {
61
    let mut raw = HashMap::new();
62
    raw.insert("port", "8080");
63
    raw.insert("workers", "3");
64

65
    match load_config(&raw) {
66
        Ok(cfg) => {
67
            println!("listening on port {}", cfg.port);
68
            println!("chunk size = {}", chunk_size(100, cfg.workers));
69
        }
70
        Err(e) => eprintln!("config error: {e}"),
71
    }
72

73
    // Recoverable path: a bad value is reported and the program keeps running.
74
    let mut bad = HashMap::new();
75
    bad.insert("port", "70000"); // > u16::MAX
76
    match load_config(&bad) {
77
        Ok(_) => println!("unexpected ok"),
78
        Err(e) => println!("rejected bad config: {e}"),
79
    }
80
}

Real output:

1
listening on port 8080
2
chunk size = 34
3
rejected bad config: key `port` has invalid number: "70000"

The two flavors of failure are visible in the signatures. load_config returns Result<Config, ConfigError>: bad config is data the caller must handle, and the program survives it. chunk_size returns a plain u32 with a documented # Panics clause: it trusts its caller, and a zero worker count would be a contradiction the config layer already ruled out — so if it ever happens, crashing is the correct, loud response. For richer error types and the anyhow/thiserror crates that production code reaches for, see custom-errors.md and anyhow-thiserror.md.

Exercises

Exercise 1: From panic to `Result`

Difficulty: Easy

Objective: Recognize when a panic is the wrong tool and convert it into a recoverable error.

Instructions: The function below panics on division by zero — but division by zero is something a caller could reasonably want to handle, not a bug. Rewrite it to return a Result<i64, MathError> where MathError is your own error type. Demonstrate both the Ok and Err paths from main.

1
// Starting point — refactor this to return a Result.
2
fn divide(numerator: i64, denominator: i64) -> i64 {
3
    if denominator == 0 {
4
        panic!("division by zero"); // recoverable; shouldn't panic
5
    }
6
    numerator / denominator
7
}

Solution

1
#[derive(Debug, PartialEq)]
2
enum MathError {
3
    DivideByZero,
4
}
5

6
fn safe_divide(numerator: i64, denominator: i64) -> Result<i64, MathError> {
7
    if denominator == 0 {
8
        return Err(MathError::DivideByZero);
9
    }
10
    Ok(numerator / denominator)
11
}
12

13
fn main() {
14
    println!("{:?}", safe_divide(10, 2));  // Ok(5)
15
    println!("{:?}", safe_divide(10, 0));  // Err(DivideByZero)
16
}

Output:

1
Ok(5)
2
Err(DivideByZero)

The caller now decides what to do with a zero denominator instead of having the program ripped out from under it.

Exercise 2: A justified panic with a documented invariant

Difficulty: Medium

Objective: Identify a case where panicking is correct and express the contract clearly.

Instructions: Write pick_wrapping<T>(slice: &[T], index: usize) -> &T that returns the element at index, wrapping around with the modulo operator so any index is valid — except when the slice is empty, which is a programmer error (there is nothing to return). Use assert! with a clear message, document the panic in a # Panics doc comment, and show it returning a value for an out-of-range index on a non-empty slice.

Solution

1
/// Picks element `index` from `slice`, wrapping around with modulo.
2
///
3
/// # Panics
4
/// Panics if `slice` is empty (there is nothing to pick).
5
fn pick_wrapping<T>(slice: &[T], index: usize) -> &T {
6
    assert!(!slice.is_empty(), "cannot pick from an empty slice");
7
    &slice[index % slice.len()]
8
}
9

10
fn main() {
11
    let colors = ["red", "green", "blue"];
12
    println!("{}", pick_wrapping(&colors, 7)); // 7 % 3 == 1 -> "green"
13
}

Output:

1
green

The empty-slice case is genuinely impossible to serve, so panicking is the right call — and the # Panics clause makes the contract explicit. Pass &[] as &[&str] and it would panic with cannot pick from an empty slice.

Exercise 3: A panic boundary with `catch_unwind`

Difficulty: Hard

Objective: Use catch_unwind for its legitimate purpose — isolating untrusted code so a panic in it does not take down the host.

Instructions: Imagine a plugin host that runs third-party closures. A misbehaving plugin should not crash the host. Write run_plugin<F: FnOnce() + UnwindSafe>(name: &str, plugin: F) that runs the closure inside std::panic::catch_unwind, prints whether it succeeded or panicked, and lets the host continue. Run one well-behaved plugin and one that panics.

Solution

1
fn run_plugin<F: FnOnce() + std::panic::UnwindSafe>(name: &str, plugin: F) {
2
    match std::panic::catch_unwind(plugin) {
3
        Ok(()) => println!("plugin `{name}` ran successfully"),
4
        Err(_) => println!("plugin `{name}` panicked; host stays up"),
5
    }
6
}
7

8
fn main() {
9
    run_plugin("good", || println!("  doing safe work"));
10
    run_plugin("bad", || panic!("plugin exploded"));
11
    println!("host still running");
12
}

Output:

1
  doing safe work
2
plugin `good` ran successfully
3

4
thread 'main' panicked at src/main.rs:10:26:
5
plugin exploded
6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
7
plugin `bad` panicked; host stays up
8
host still running

The panic message still prints (via the panic hook), but the unwind is caught at the host boundary, so the program survives and the next plugin runs. This is the legitimate use of catch_unwind — note it requires the closure to be UnwindSafe, and under panic = "abort" it can never actually catch anything: the process is terminated at the panic point before the catch can return Err.

Panicking: panic! vs Recoverable Errors

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

What panic! actually does

Backtraces are opt-in

Unwinding runs your destructors

A panic kills the thread, not necessarily the program

Key Differences

Two failure mechanisms, not one

Unwinding vs. aborting

Common Pitfalls

Pitfall 1: Treating panic! like JavaScript throw

Pitfall 2: Using catch_unwind as a general try/catch

Pitfall 3: Assuming abort still runs cleanup

Pitfall 4: Expecting a panic to print a stack trace by default

Pitfall 5: Forgetting that a panicked thread does not stop main

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: From panic to Result

Exercise 2: A justified panic with a documented invariant

Exercise 3: A panic boundary with catch_unwind

Panicking: `panic!` vs Recoverable Errors

What `panic!` actually does

Pitfall 1: Treating `panic!` like JavaScript `throw`

Pitfall 2: Using `catch_unwind` as a general `try/catch`

Pitfall 3: Assuming `abort` still runs cleanup

Pitfall 5: Forgetting that a panicked thread does not stop `main`

Exercise 1: From panic to `Result`

Exercise 3: A panic boundary with `catch_unwind`