أفضل الممارسات لترجمة الاستثناءات في فئة غلاف C++/CLI

Question

أنا أكتب فئة مجمعة .NET لفئة أصلية موجودة والتي تطرح استثناءات.ما هي أفضل الممارسات للترجمة بين استثناءات C++ الأصلية والاستثناءات المُدارة؟أمسك وأعد الرمي على أساس فردي (على سبيل المثال.std::invalid_argument -> System.System.ArgumentException)؟هل هناك خريطة تم رسمها بالفعل في مكان ما؟

Answer 1

لا يوجد رسم خرائط قياسي أعرفه.ما قمت به في الماضي هو ترجمة ما أعرفه، وحظر الالتقاط لـ System.Runtime.InteropServices.SEHException.سيتم تحويل جميع الاستثناءات غير المترجمة إلى هذا الاستثناء.طالما أن لديك بنية تصحيح الأخطاء للتعليمات البرمجية التي تطرح الاستثناء، فيجب أن تحصل على تتبع مكدس جيد.ثم يمكنك الذهاب وإلقاء نظرة على الاستثناء وكتابة الغلاف.

لكن في المشروع الأخير الذي اضطررت إلى القيام بذلك، ذهبت إلى شيء أكثر بساطة، وانتهى بي الأمر بكتابة اثنين من مشتقات System.Exception لـ logic_error وruntime_error.ثم سألتقط هاتين الفئتين الأساسيتين وأستخدم typeid(err) لكتابة رسالة .NET التي تم طرحها.بهذه الطريقة لم "أفقد" ما تم إلقاؤه من لغة C++ ولكن لم أضطر إلى تعيين كل شيء باستثناء أهمها.

Answer 2

يبدو أن رسم الخرائط الفردية هو النهج الأكثر عقلانية بالنسبة لي.من الصعب أن يكون التعيين "العالمي" ممكنًا بسبب الاستثناءات الخاصة بالتطبيقات، على الرغم من وجود بعض التعيينات الواضحة لفئات استثناءات STL.

هناك أيضًا مشكلة تتعلق باستثناءات SEH من التعليمات البرمجية غير المُدارة.اعتمادًا على حالتك، قد يكون من الضروري الإمساك بها ولفها أيضًا.

Answer 3

أعتقد أن ذلك يعتمد على تصميم الغلاف.إذا كانت واجهة برنامج تضمين المدير مطابقة تقريبًا لواجهة المكتبة غير المُدارة، فقم بإعادة طرح الاستثناءات بنسبة 1:1.إذا كنت تقوم بتغيير الواجهة بشكل كبير، فقم بطرح الاستثناءات الأكثر ملاءمة للواجهة الجديدة.وفي كلتا الحالتين، تأكد من أن برنامج التضمين يطرح استثناءات في أي وقت يتعذر فيه إكمال العملية لتكون متوافقة مع إرشادات تصميم .NET.

Answer 4

ماذا تحاول ان تفعل حقا؟

يقوم Interop بالفعل بترجمة الاستثناءات الأصلية إلى استثناءات مُدارة، بما في ذلك استثناءات SEH.ومع ذلك، التصميم الجيد يفرض ذلك الجميع يجب اكتشاف الاستثناءات على مستوى واجهة برمجة التطبيقات الأصلية.لا ينبغي أن تحيد عن هذا إلا إذا كان هناك سبب وجيه.نحن لا نعرف ما يكفي عن التصميم الخاص بك.