Skip to content

Commit 1aee725

Browse files
committed
clarify recoverable vs non-recoverable panics
1 parent a1c37fc commit 1aee725

File tree

1 file changed

+10
-7
lines changed

1 file changed

+10
-7
lines changed

src/panic.md

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -16,13 +16,16 @@ over panic behavior:
1616
1717
## Unwinding
1818

19-
Panicking may either be recoverable or non-recoverable, though its behavior
20-
must be uniform throughout program execution. A recoverable panic "unwinds"
21-
Rust frames, just as C++'s `throw` unwinds C++ frames. This means that as the
22-
panic traverses Rust frames, live objects in those frames that [implement
23-
`Drop`][destructors] will have their `drop` methods called. Thus, if panic
24-
recovery does occur (for instance at a thread boundary), the objects will have
25-
been "cleaned up" just as if they had gone out of scope normally.
19+
Panicking may either be recoverable or non-recoverable, though it can be
20+
configured (via `panic=abort`) to always be non-recoverable. (The converse is
21+
not true: `panic=unwind` does not guarantee that all panics are recoverable,
22+
only that panicking via the `panic!` macro and similar standard library
23+
mechanisms is recoverable.) A recoverable panic "unwinds" Rust frames, just as
24+
C++'s `throw` unwinds C++ frames. This means that as the panic traverses Rust
25+
frames, live objects in those frames that [implement `Drop`][destructors] will
26+
have their `drop` methods called. Thus, if panic recovery does occur (for
27+
instance at a thread boundary), the objects will have been "cleaned up" just as
28+
if they had gone out of scope normally.
2629

2730
> **Note**: As long as this guarantee of resource-cleanup is preserved,
2831
> "unwinding" may be implemented without actually using the mechanism used by

0 commit comments

Comments
 (0)