@@ -16,13 +16,16 @@ over panic behavior:
16
16
17
17
## Unwinding
18
18
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.
26
29
27
30
> ** Note** : As long as this guarantee of resource-cleanup is preserved,
28
31
> "unwinding" may be implemented without actually using the mechanism used by
0 commit comments