Rust-FFI-Unwinding: eine explizite Grenze für Panics und Exceptions wählen

Worum es geht

Der Rustonomicon unterscheidet ABI-Zeichenketten, die Unwinding zulassen, von solchen, die es nicht tun. Ein Rust-Panic, der eine Nicht-Unwinding-Grenze erreicht, führt zum Abbruch; eine fremde Exception, die durch eine solche Grenze in Rust eintritt, verursacht undefiniertes Verhalten. Ausserdem wird festgehalten, dass panic=abort unabhängig von der gewählten ABI weiterhin abbricht und dass catch_unwind kein allgemeiner Fänger für fremde Exceptions ist. Rustonomicon: FFI

Warum es wichtig ist

Ein Agent, der eine C++-Bibliothek umschliesst, fügt möglicherweise catch_unwind um einen Aufruf ein und nimmt an, dass alle Fehler zu Fehlerwerten werden. Vor dem Schreiben von Recovery-Code festlegen, welche Sprache für welchen Fehlermechanismus zuständig ist. Die vorgeschlagene Grenzüberprüfung macht die Fehlerdarstellung zu einer expliziten Schnittstellenentscheidung.

So wird es angewendet

• Jede exportierte Funktion und jeden Callback erfassen. Für jede/n die ABI, die Panic-Strategie, das Verhalten bei fremden Exceptions und den Vertrag für gewöhnliche Fehlerrückgaben festhalten.
• Erwartete Fehler bevorzugt auf der Seite, die sie versteht, in die dokumentierte Status- oder Ergebnisdarstellung der Schnittstelle übersetzen. Festlegen, wie eine Fehlermeldung gespeichert wird und wie lange sie gültig bleibt.
• Wenn Unwinding absichtlich zugelassen ist, alle dazwischenliegenden Frames und Cleanup-Annahmen gegen den passenden ABI-Vertrag prüfen. Die Änderung nicht allein deshalb vornehmen, um einen beobachteten Abbruch zu stoppen.
• Separate Fixtures für einen gewöhnlichen Fehler, einen Rust-Panic und eine fremde Exception vorschlagen. Jede potenziell terminierende Fixture in einem isolierten Kindprozess ausführen und deren Beendigung einordnen, ohne die Terminierung als wiederherstellbare Rückgabe zu behandeln.
• Ressourcenbereinigung und Callback-Verhalten für jeden unterstützten Fehlerpfad prüfen. Nicht unterstützte Kombinationen in der öffentlichen Binding-Dokumentation explizit ausweisen.

Stolpersteine

Kompatibilität nicht von einem einzelnen Compiler und einer einzelnen Optimierungsstufe ableiten. Ein Fangmechanismus einer Sprache gilt nicht automatisch auch für die Exception einer anderen Sprache. Die richtige Grenze hängt zudem von der fremden Bibliothek und der Build-Konfiguration ab, sodass ein generischer Wrapper keine universelle Wiederherstellung versprechen kann. Dieser Artikel beschreibt einen Prüfplan und beansprucht kein durchgeführtes sprachübergreifendes Exception-Experiment.