Meilleure pratique pour la traduction d'exceptions dans la classe d'encapsulation C++/CLI

Question

J'écris une classe .NET wrapper pour une classe native existante qui génère des exceptions. Quelles sont les meilleures pratiques de traduction entre les exceptions C++ natives et les exceptions gérées? Attraper et relancer sur une base de un à un (par exemple std :: invalid_argument -> System.System.ArgumentException)? Y a-t-il une cartographie déjà établie quelque part?

Answer 1

Il n'existe pas de mappage standard que je connaisse. Ce que j'ai fait dans le passé est de traduire ceux que je connais, et un bloc catch pour System.Runtime.InteropServices.SEHException. Toutes les exceptions non traduites seront transformées en cette exception. Tant que vous avez une version de débogage du code qui lance l'exception, vous devriez obtenir une belle trace de pile. Ensuite, vous pouvez aller voir l'exception et écrire le wrapper.

Mais sur le dernier projet que j'ai dû faire, je suis allé avec quelque chose de beaucoup plus simple, j'ai fini par écrire quelques dérivés System.Exception pour logic_error et runtime_error. Ensuite, j'attraperais ces 2 classes de base et j'utiliserais typeid (err) pour écrire le message .NET qui a été lancé. De cette façon, je n'ai pas "perdu" ce qui était lancé depuis le C++ mais je n'ai pas eu à tout cartographier sauf les plus importants.

Answer 2

La cartographie en tête-à-tête semble la meilleure approche pour moi. Le mappage "universel" est difficilement possible en raison d'exceptions spécifiques aux applications, bien qu'il existe un mappage évident pour les classes d'exceptions STL.

Il existe également un problème d'exceptions SEH du code non managé. Selon votre situation, il peut être nécessaire de les attraper et de les envelopper aussi.

Answer 3

Je pense que cela dépend de la conception de l'emballage. Si l'interface du gestionnaire wrapper est presque identique à l'interface de la bibliothèque non gérée, relancez les exceptions 1: 1. Si vous modifiez l'interface de manière significative, lancez les exceptions les plus appropriées pour la nouvelle interface. Dans tous les cas, assurez-vous que l'encapsuleur génère des exceptions chaque fois qu'une opération ne peut pas être terminée pour être conforme aux consignes de conception .NET.

Answer 4

Qu'essayez-vous vraiment de faire?

Interop traduit déjà les exceptions natives en Gérés, y compris les exceptions SEH. Cependant, une bonne conception dicte que les exceptions ALL doivent être interceptées au niveau de l'API native. Vous ne devriez pas dévier de ceci à moins qu'il y ait une bonne raison. Nous n'en savons pas assez sur votre conception.