فئة apext::tsync::TsyncFvmException

تُستخدم فئة الاستثناء apext::tsync::TsyncFvmException لتمكين Freshness Value Manager في الوحدة tsync من الإبلاغ عن الحالات الخاطئة أثناء معالجة قيم الحداثة. عند اكتشاف خطأ ما، تتم تهيئة الاستثناء صراحةً مع تمرير ara::core::ErrorCode محدد ويتم إطلاقه في مسار التحكم [SWS_TS_14204]. وكشروط أساسية، تم التصريح عن المنشئ كـ noexcept وصُممت الفئة لتكون آمنة خيطياً بالكامل وآمنة استثنائياً لضمان تمرير متين للخطأ في الأنظمة المتزامنة [SWS_TS_14204].

المزيد ›

السياق

تعد الفئة apext::tsync::TsyncFvmException فئة استثناء متخصصة ضمن الوحدة tsync في AUTOSAR Adaptive Platform. وفقاً لمواصفة الوحدة، تُستخدم الفئة لتغليف وتمرير حالات الخطأ التي يطلقها Freshness Value Manager. تم تعريف الفئة كفئة فرعية مباشرة لـ ara::core::Exception، مما يضمن المعالجة القياسية لاستثناءات C++‎ للأخطاء في نطاق إدارة قيم الحداثة.

من بين أطراف التفاعل الأساسية: Freshness Value Manager كجهة مُطلقة، ومكونات البرمجيات المستخدمة، وخدمات المزامنة التي تطلب عمليات التحقق من الحداثة لعلاقات الاتصال المؤمنة. إذا حدث شرط استثنائي أثناء التحقق من قيمة الحداثة أو حسابها، ينشئ Freshness Value Manager هذا الكائن لإشعار المستدعي. يتم التصريح وتعريف الواجهة عبر ملف الترويسة apext/tsync/fvm_error_domain.h [SWS_TS_14204].

دورة الحياة

ترتبط دورة حياة كائن من النوع apext::tsync::TsyncFvmException بدورة حياة استثناءات C++‎ العادية. يتم الإنشاء عبر المنشئ الصريح TsyncFvmException الذي يستقبل رمز خطأ من النوع ara::core::ErrorCode [SWS_TS_14204]. تم التصريح عن هذا المنشئ بالمواصفة noexcept، مما يضمن أن إنشاء الكائن نفسه آمن استثنائياً ولا يطلق استثناءات ثانوية تحت أي ظرف [SWS_TS_14204].

تم تحديد الفئة صراحةً بأنها آمنة استثنائياً (exception safe) وآمنة خيطياً (thread-safe) [SWS_TS_14204]. يتيح ذلك إنشاء النُسخ وتمريرها بأمان حتى في بيئات التشغيل المعقدة متعددة الخيوط دون خطر حدوث تسابق على البيانات (Data races).

تفسير: فيما يتعلق بملكية الكائن، يُطلق الاستثناء عادةً بالقيمة ويتم التقاطه في مكدس الاستدعاءات كمرجع لكائن ثابت (const apext::tsync::TsyncFvmException&). سؤال Q-6e8c4ad080550a52 (مفتوح) لا يمر الكائن بأي تغييرات أخرى في حالته بعد إنشائه؛ ويتم تدميره تلقائياً عند مغادرة كتلة catch المعالجة.

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

يتم مسار الاستخدام العادي ضمن إطار عملية تحقق من صحة قيم الحداثة أو تحديثها يقوم بها Freshness Value Manager. إذا اكتشف المدير انتهاكاً لسلامة الحداثة أو خطأ معالجة داخلياً، فإنه يبدأ معالجة الخطأ:

1. تحديد الخطأ: يكتشف Freshness Value Manager حالة خطأ وينشئ كائن ara::core::ErrorCode مطابقاً.
2. التهيئة: تتم تهيئة كائن الاستثناء بتمرير رمز الخطأ عبر المنشئ [SWS_TS_14204].
3. الإطلاق: يتم إطلاق الاستثناء باستخدام throw في سياق الاستدعاء.
4. التقييم: يلتقط التطبيق أو الطبقة المستدعية الاستثناء ويصل إلى رمز الخطأ المضمن لاتخاذ تدابير ملائمة لمعالجة الخطأ أو تقليل مستوى الخدمة (Degradation).

مخطط تسلسلي: المسار النموذجي لمعالجة الخطأ باستخدام apext::tsync::TsyncFvmException بدءاً من الاكتشاف في Freshness Value Manager حتى الالتقاط في جهة الاستدعاء. المصادر: [SWS_TS_14204]

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

نظراً لأن apext::tsync::TsyncFvmException مصممة في حد ذاتها كآلية للإشعار بالأخطاء، فإن سيناريوهات الأخطاء الوظيفية تعود بالأساس إلى التعامل الخاطئ مع الاستثناء. ويُشترط لإنشائها تمرير ara::core::ErrorCode صالح إلى المنشئ [SWS_TS_14204]. ومع ذلك، نظراً لأن المنشئ معرّف كـ noexcept، يظل إنشاء الكائن مستقراً حتى مع قيم أخطاء غير متوقعة [SWS_TS_14204].

نظراً لتحديد ترويسة التعريف apext/tsync/fvm_error_domain.h مسبقاً، يُرجح أن ينتمي errorCode المغلف بصورة تفضيلية إلى نطاق أخطاء Freshness Value Manager المتخصص [SWS_TS_14204]. سؤال Q-91a4f2d66128bb91 (مفتوح) وينشأ سيناريو خطأ جسيم إذا لم تتم معالجة الاستثناء المُطلق على مستوى النظام بواسطة أي كتلة catch؛ إذ يؤدي ذلك وفقاً لدلالات C++‎ القياسية حتماً إلى استدعاء std::terminate وبالتالي إلى إنهاء العملية. ومع ذلك، وبفضل الأمان الخيطي المضمون وفقاً لـ [SWS_TS_14204]، تُستبعد الأخطاء الناتجة عن عمليات الوصول المتزامنة من خيوط تنفيذ متوازية.