From af096494bcebe11e8158e7ee9ea6e97b6cc50f3f Mon Sep 17 00:00:00 2001 From: Kyle J Strand Date: Sun, 25 Aug 2024 14:42:16 -0600 Subject: [PATCH] clarify recoverable vs non-recoverable panics --- src/panic.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/panic.md b/src/panic.md index 2f425b822..84a034054 100644 --- a/src/panic.md +++ b/src/panic.md @@ -16,13 +16,16 @@ over panic behavior: ## Unwinding -Panicking may either be recoverable or non-recoverable, though its behavior -must be uniform throughout program execution. A recoverable panic "unwinds" -Rust frames, just as C++'s `throw` unwinds C++ frames. This means that as the -panic traverses Rust frames, live objects in those frames that [implement -`Drop`][destructors] will have their `drop` methods called. Thus, if panic -recovery does occur (for instance at a thread boundary), the objects will have -been "cleaned up" just as if they had gone out of scope normally. +Panicking may either be recoverable or non-recoverable, though it can be +configured (via `panic=abort`) to always be non-recoverable. (The converse is +not true: `panic=unwind` does not guarantee that all panics are recoverable, +only that panicking via the `panic!` macro and similar standard library +mechanisms is recoverable.) A recoverable panic "unwinds" Rust frames, just as +C++'s `throw` unwinds C++ frames. This means that as the panic traverses Rust +frames, live objects in those frames that [implement `Drop`][destructors] will +have their `drop` methods called. Thus, if panic recovery does occur (for +instance at a thread boundary), the objects will have been "cleaned up" just as +if they had gone out of scope normally. > **Note**: As long as this guarantee of resource-cleanup is preserved, > "unwinding" may be implemented without actually using the mechanism used by