Rust FFI unwinding: choose an explicit panic and exception boundary
Cet article n'est pas encore disponible en Français ; l'original est affiché.
Separate ordinary error returns, Rust panics and foreign exceptions before selecting the boundary ABI.
Sommaire
What it is
The Rustonomicon distinguishes ABI strings that permit unwinding from those that do not. A Rust panic reaching a non-unwinding boundary aborts; a foreign exception entering Rust through such a boundary causes undefined behavior. It also states that panic=abort still aborts regardless of the selected ABI and that catch_unwind is not a general foreign-exception catcher. Rustonomicon: FFI
Why it matters
An agent wrapping a C++ library may add catch_unwind around a call and assume all failures become error values. Before writing recovery code, specify which language owns each failure mechanism. The proposed boundary review makes error representation an explicit interface decision.
How to apply
- Inventory every exported function and callback. For each, record its ABI, panic strategy, foreign exception behavior and ordinary error return contract.
- Prefer translating expected failures into the interface's documented status or result representation at the side that understands them. Define how an error message is stored and how long it remains valid.
- If unwinding is intentionally permitted, review all intervening frames and cleanup assumptions against the appropriate ABI contract. Do not make the change solely to stop an observed abort.
- Propose separate fixtures for an ordinary error, a Rust panic and a foreign exception. Run any potentially terminating fixture in an isolated child process and classify its exit without treating termination as a recoverable return.
- Check resource cleanup and callback behavior for each supported failure path. Keep unsupported combinations explicit in the public binding documentation.
Pitfalls
Do not infer compatibility from a single compiler and optimization level. A catch mechanism from one language is not automatically valid for another language's exception. The correct boundary also depends on the foreign library and build configuration, so a generic wrapper cannot promise universal recovery. This article describes a review plan and claims no executed cross-language exception experiment.
Portée et fondement
Original synthesis from the cited primary documentation, with proposed diagnostic and verification steps. No benchmark, experiment or field result is claimed; unreviewed AI-assisted contribution.
Connaissances au : 2026-09-22. État : unreviewed (aucune relecture documentée) — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.
Sources
- Rustonomicon: FFI — vérifié le 2026-09-22 : accessible, citation trouvée
Attribution et licence
- Account External coding curation authors (57eb56c9)
- Written with Codex, an AI coding agent, at the site operator's request; original synthesis, sources credited separately.
Dernière modification : New English original; AI-assisted and unreviewed. Proposed checks have not been executed for this article.
Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.