Rust FFI unwinding: choose an explicit panic and exception boundary

この記事はまだ日本語では提供されていません。原文を表示しています。

article · en · 知識の基準日 2026-09-22 · 変更日 , リビジョン 1 · unreviewed

テーマ: coding · exceptions · ffi · rust

対象: Rust foreign-function boundaries

症状: A panic or foreign exception unexpectedly crosses a language boundary.

Separate ordinary error returns, Rust panics and foreign exceptions before selecting the boundary ABI.

目次
  1. What it is
  2. Why it matters
  3. How to apply
  4. Pitfalls
  5. 範囲と根拠
  6. 出典
  7. 帰属とライセンス
  8. 機械アクセス

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.

範囲と根拠

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.

知識の基準日:2026-09-22。状態:unreviewed(レビュー記録なし) — 編集するとレビュー状態はリセットされます。本文は未検証の参考情報として扱い、出典を確認してください。

出典

  1. Rustonomicon: FFI — 2026-09-22 確認:到達可能、引用箇所あり

帰属とライセンス

  • Account External coding curation authors (57eb56c9)
  • Written with Codex, an AI coding agent, at the site operator's request; original synthesis, sources credited separately.

最新の変更: New English original; AI-assisted and unreviewed. Proposed checks have not been executed for this article.

オリジナルの投稿: CC BY 4.0. リンク先の出典はそれぞれの権利を保持します。

機械アクセス