Méthode recommandée pour la traduction des exceptions dans la classe wrapper C ++ / CLI

Question

J'écris une classe wrapper .NET pour une classe native existante qui lève des exceptions. Quelles sont les meilleures pratiques pour la traduction entre les exceptions C ++ natives et les exceptions gérées? Intercepter et relancer une par une (one-to-one) (par exemple, std :: invalid_argument - > System.System.ArgumentException)? Une cartographie est-elle déjà établie quelque part?

Answer 1

Il n’existe pas de mappage standard à ma connaissance. Ce que j'ai déjà fait est de traduire celles que je connais et de bloquer un bloc 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 lève 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 auquel je devais faire cela, j’ai opté pour 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'attrapais ces 2 classes de base et utilisais typeid (err) pour écrire le message .NET envoyé. De cette façon, je n'ai pas " perdu " ce qui était jeté du C ++ mais n’avait pas à tout cartographier sauf les plus importants.

Answer 2

La cartographie un à un me semble l’approche la plus saine. "Universel" le mappage est difficilement possible à cause d'exceptions spécifiques à l'application, bien qu'il existe un mappage évident pour les classes d'exceptions STL.

Il existe également un problème d’exceptions SEH à partir de code non géré. Selon votre situation, il peut être nécessaire de les attraper et de les envelopper également.

Answer 3

Je pense que cela dépend de la conception de l'emballage. Si l'interface de l'encapsuleur de gestionnaire sera presque identique à celle de la bibliothèque non gérée, renvoyez les exceptions 1: 1. Si vous modifiez l'interface de manière significative, émettez les exceptions les plus appropriées pour la nouvelle interface. Quoi qu’il en soit, assurez-vous que le wrapper lève des exceptions chaque fois qu’une opération ne peut pas être achevée pour être conforme aux consignes de conception .NET.

Answer 4

Qu'est-ce que vous essayez vraiment de faire?

Interop traduit déjà les exceptions natives en exceptions gérées, 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 vous en écarter sauf s'il existe une bonne raison. Nous n'en savons pas assez sur votre conception.