Best practice per la traduzione di eccezioni nella classe wrapper C ++ / CLI

Question

Sto scrivendo una classe wrapper .NET per una classe nativa esistente che genera eccezioni. Quali sono le migliori pratiche per la traduzione tra eccezioni C ++ native ed eccezioni gestite? Cattura e rilancia su base uno-a-uno (ad es. Std :: invalid_argument - > System.System.ArgumentException)? Esiste già una mappatura elaborata da qualche parte?

Answer 1

Non esiste una mappatura standard che io conosca. Quello che ho fatto in passato è tradurre quelli che conosco e un blocco catch per System.Runtime.InteropServices.SEHException. Tutte le eccezioni non tradotte verranno trasformate in tale eccezione. Finché hai una build di debug del codice che genera l'eccezione, dovresti ottenere una bella traccia dello stack. Quindi puoi andare a vedere l'eccezione e scrivere il wrapper.

Ma sull'ultimo progetto su cui ho dovuto farlo, sono andato con qualcosa di molto più semplice, ho finito per scrivere un paio di derivati ??System.Exception per logic_error e runtime_error. Quindi prenderei quelle 2 classi base e userei typeid (err) per scrivere il messaggio .NET che è stato lanciato. In questo modo non ho perso " perso " ciò che veniva generato dal C ++ ma non doveva mappare tutto tranne quelli più importanti.

Answer 2

Il mapping one-to-one sembra l'approccio più sano per me. & Quot; Universale " il mapping è difficilmente possibile a causa di eccezioni specifiche dell'applicazione, sebbene esista un mapping evidente per le classi di eccezioni STL.

Inoltre c'è un problema di eccezioni SEH dal codice non gestito. A seconda della situazione, potrebbe essere necessario catturarli e avvolgerli.

Answer 3

Penso che dipenda dal design dell'involucro. Se l'interfaccia del wrapper del gestore sarà quasi identica all'interfaccia della libreria non gestita, ripeti le eccezioni 1: 1. Se stai modificando l'interfaccia in modo significativo, lancia eccezioni più appropriate per la nuova interfaccia. In entrambi i casi, assicurarsi che il wrapper generi eccezioni ogni volta che un'operazione non può essere completata per essere coerente con le linee guida di progettazione .NET.

Answer 4

Cosa stai davvero cercando di fare?

Interop traduce già le eccezioni native in gestite, comprese le eccezioni SEH. Tuttavia, un buon design impone che le eccezioni ALL debbano essere individuate a livello di API nativa. Non dovresti deviare da questo a meno che non ci sia una buona ragione. Non sappiamo abbastanza del tuo design.