Déroulement de pile (unwinding) en Rust FFI : choisir explicitement une frontière de panique et d'exception

Ce que c'est

Le Rustonomicon distingue les chaînes d'ABI qui autorisent le déroulement de pile (unwinding) de celles qui ne l'autorisent pas. Une panique Rust atteignant une frontière n'autorisant pas le déroulement de pile provoque un abandon (abort) ; une exception étrangère entrant en Rust par une telle frontière provoque un comportement indéfini. Il indique aussi que panic=abort provoque toujours un abandon, quelle que soit l'ABI sélectionnée, et que catch_unwind n'est pas un mécanisme général de capture d'exceptions étrangères. Rustonomicon: FFI

Pourquoi c'est important

Un agent encapsulant une bibliothèque C++ peut ajouter catch_unwind autour d'un appel et présumer que tous les échecs se transforment en valeurs d'erreur. Avant d'écrire du code de récupération, préciser quel langage possède chaque mécanisme d'échec. La revue de frontière proposée fait de la représentation des erreurs une décision d'interface explicite.

Comment l'appliquer

• Inventorier chaque fonction et rappel (callback) exportés. Pour chacun, consigner son ABI, sa stratégie de panique, son comportement face aux exceptions étrangères et son contrat de retour d'erreur ordinaire.
• Préférer traduire les échecs attendus vers la représentation de statut ou de résultat documentée de l'interface, du côté qui les comprend. Définir comment un message d'erreur est stocké et pendant combien de temps il reste valide.
• Si le déroulement de pile est délibérément autorisé, examiner toutes les trames intermédiaires et les hypothèses de nettoyage par rapport au contrat d'ABI approprié. Ne pas effectuer ce changement dans le seul but d'arrêter un abandon observé.
• Proposer des scénarios de test distincts pour une erreur ordinaire, une panique Rust et une exception étrangère. Exécuter tout scénario potentiellement terminal dans un processus enfant isolé, et classifier sa sortie sans traiter la terminaison comme un retour récupérable.
• Vérifier le nettoyage des ressources et le comportement des rappels pour chaque chemin d'échec pris en charge. Garder les combinaisons non prises en charge explicites dans la documentation publique des liaisons (bindings).

Pièges

Ne pas inférer une compatibilité à partir d'un seul compilateur et d'un seul niveau d'optimisation. Un mécanisme de capture propre à un langage n'est pas automatiquement valide pour l'exception d'un autre langage. La frontière correcte dépend aussi de la bibliothèque étrangère et de la configuration de compilation, si bien qu'un wrapper générique ne peut pas promettre une récupération universelle. Cet article décrit un plan de revue et ne revendique aucune expérimentation d'exceptions inter-langages effectivement exécutée.