فئة ara::diag::DiagOfferException

تُستخدم الفئة ara::diag::DiagOfferException كنوع استثناء C++ محدد، تطرحه فئات التشخيص في AUTOSAR Adaptive Platform للإشارة إلى الأخطاء ([SWS_DM_00985]). وهي مشتقة من ara::core::Exception ويتم إنشاء مثيل لها بأمان لمؤشرات الترابط عبر مُنشئ noexcept مع تحديد ara::core::ErrorCode ([SWS_DM_00986]). يُرجح أن يحدث الاستثناء بشكل أساسي عند فشل تقديم خدمات التشخيص، ويجب التقاطه بواسطة التطبيق المستدعي لمنع الإنهاء غير المنضبط للعملية. سؤال (مفتوح)

المزيد ›

السياق

الفئة ara::diag::DiagOfferException هي نوع استثناء مركزي لوحدة التشخيص داخل AUTOSAR Adaptive Platform ([SWS_DM_00985]، SWS Diagnostics §8.11.6 «Class: DiagOfferException»). وفقًا لمواصفاتها، فإنها تمثل استثناءً يتم إطلاقه بواسطة فئات التشخيص ("Exception type thrown by Diag classes"). تشتق الفئة علنًا من الفئة الأساسية ara::core::Exception ويتم تضمينها في التطبيقات عبر الترويسة ara/diag/diag_error_domain.h ([SWS_DM_00986]).

من بين أطراف التفاعل الأساسية الفئات الوظيفية لإدارة التشخيص، وبنية الأخطاء الأساسية لـ AUTOSAR Adaptive (الممثلة بواسطة ara::core::ErrorCode)، بالإضافة إلى برمجيات التطبيق التي تقدم خدمات التشخيص. يشير اسم الفئة إلى أن هذا الاستثناء يُستخدم على الأرجح عند فشل تقديم أو تسجيل خدمات التشخيص بواسطة فئات Diag المقابلة (تفسير). سؤال Q-47046201c9fd38c3 (مفتوح)

دورة الحياة

يتم إنشاء مثيل لـ ara::diag::DiagOfferException عبر منشئها الوحيد المحدد explicit DiagOfferException(ara::core::ErrorCode err) noexcept ([SWS_DM_00986]، SWS Diagnostics §8.11.6.1.1.1 «DiagOfferException»). وبذلك يتم ربط الاستثناء مباشرة بكود خطأ ملموس. وبما أن المنشئ مُعلن كـ noexcept، فمن المضمون عدم حدوث أخطاء أخرى أو استثناءات تعاودية أثناء إنشاء كائن الاستثناء نفسه ([SWS_DM_00986]).

فيما يتعلق بدورة الحياة، تخضع الفئة للآليات المعتادة لمعالجة استثناءات ++C: يتم إنشاؤها في ذاكرة الاستثناءات لبيئة التشغيل، وتُنقل عبر مكدس الاستدعاءات، ويتم تحريرها تلقائيًا بعد معالجة كتلة catch المعالجة. وفقًا للمواصفة، فإن الإنشاء آمن خيطيًا (thread-safe) وآمن من الاستثناءات (exception-safe) ([SWS_DM_00986]). لا يمتلك كائن الاستثناء بعد إنشائه أي تغييرات معقدة في الحالة الداخلية؛ ويُرجح أن يعمل كغلاف نقل غير قابل للتغيير لكود الخطأ الممرر (تفسير). سؤال Q-09c6e0ad610717e9 (مفتوح)

مسار الاستخدام

ينقسم المسار النموذجي لاستخدام ara::diag::DiagOfferException إلى المراحل التالية:

• يستدعي تطبيقٌ دالةً تابعة لفئة تشخيص لتوفير خدمة تشخيص أو منفذ (عملية Offer).
• تكتشف فئة التشخيص حالة خطأ أثناء التهيئة أو التسجيل وتقوم بإنشاء مثيل مناسب من ara::core::ErrorCode.
• تنشئ فئة التشخيص مثيلًا من ara::diag::DiagOfferException مع تمرير كود الخطأ هذا ([SWS_DM_00986]) وتطلق هذا الاستثناء.
• تلتقط برمجيات التطبيق المستدعية الاستثناء ضمن كتلة try-catch.
• يستخرج المستدعي كود الخطأ من الاستثناء ويبدأ استراتيجيات مناسبة للإخفاق أو إعادة المحاولة.

مخطط تسلسلي: المسار النموذجي عند الإشعار بخطأ ومعالجته عبر DiagOfferException. المصادر: [SWS_DM_00985]، [SWS_DM_00986].

سيناريوهات الأخطاء

يعمل ara::diag::DiagOfferException نفسه كآلية إشعار لحالات الخطأ. كشرط مسبق لإنشاء المثيل، يجب أن يتوفر للمثيل المستدعي ara::core::ErrorCode صالح ([SWS_DM_00986]). وبما أن المنشئ مُعرَّف كـ noexcept، فإن إنشاء المثيل لا يؤدي تحت أي ظرف إلى استثناءات ثانوية ([SWS_DM_00986]).

إذا لم تلتقط البرمجيات المطبقة استثناء DiagOfferException المُطلق، فإن ذلك يؤدي افتراضيًا إلى استدعاء std::terminate وبالتالي إلى انهيار غير منضبط للعملية. من خلال الوراثة من ara::core::Exception، فمن المتوقع على الأرجح أنه بالإضافة إلى الالتقاط المخصص لـ ara::diag::DiagOfferException، يمكن أيضًا تفعيل معالج عام لـ ara::core::Exception (تفسير)، لضمان تحمل قوي للأخطاء على مستوى العملية. سؤال Q-d0cf602a077c4dae (مفتوح)