C++/CLI ラッパー クラスで例外を変換するためのベスト プラクティス

Question

例外をスローする既存のネイティブ クラスの .NET ラッパー クラスを作成しています。ネイティブ C++ 例外とマネージ例外の間の変換のベスト プラクティスは何ですか?1 対 1 ベースでキャッチして再スローします (例:std::invalid_argument -> System.System.ArgumentException)?どこかにすでに作成されたマッピングはありますか?

Answer 1

私が知っている標準のマッピングはありません。私が過去に行ったことは、知っているものと System.Runtime.InteropServices.SEHException の catch ブロックを翻訳することです。すべての非翻訳例外はその例外に変換されます。例外をスローしているコードのデバッグ ビルドがある限り、適切なスタック トレースが得られるはずです。次に、例外を調べてラッパーを作成します。

しかし、これを行う必要があった最後のプロジェクトでは、もっと単純なものを使用し、最終的に、logic_error と runtime_error の System.Exception 派生関数をいくつか作成しました。次に、これら 2 つの基本クラスをキャッチし、typeid(err) を使用して、スローされた .NET メッセージを書き込みます。この方法では、C++ からスローされたものを「失う」ことはなく、最も重要なものを除いてすべてをマップする必要はありませんでした。

Answer 2

私にとっては、1 対 1 のマッピングが最も賢明なアプローチのように思えます。STL 例外クラスの明らかなマッピングはいくつかありますが、アプリケーション固有の例外のため、「ユニバーサル」マッピングはほとんど不可能です。

また、アンマネージ コードからの SEH 例外の問題もあります。状況によっては、捕まえて包むことも必要になるかもしれません。

Answer 3

包装紙のデザインにもよると思います。マネージャー ラッパーのインターフェイスがアンマネージ ライブラリのインターフェイスとほぼ同じである場合は、例外を 1:1 で再スローします。インターフェイスを大幅に変更する場合は、新しいインターフェイスに最も適切な例外をスローします。いずれの場合も、.NET 設計ガイドラインとの一貫性を保つために、操作が完了できない場合には必ずラッパーが例外をスローするようにしてください。

Answer 4

本当に何をしようとしているのですか？

Interop は、SEH 例外を含むネイティブ例外をマネージド例外にすでに変換しています。ただし、優れたデザインには次のことが求められます。 全て 例外はネイティブ API レベルでキャッチされる必要があります。正当な理由がない限り、これを逸脱すべきではありません。私たちはあなたのデザインについて十分に知りません。