classe ara::diag::DiagReportingException

La classe d'exception ara::diag::DiagReportingException sert à la signalisation synchrone d'états d'erreur survenant lors d'opérations au sein de classes de diagnostic de l'Adaptive Platform (AUTOSAR_AP_SWS_Diagnostics §8.11.8 « Class: DiagReportingException »). Elle est explicitement instanciée avec un ara::core::ErrorCode spécifique et transmet celui-ci à l'application appelante [SWS_DM_00988] à des fins d'analyse de la cause de l'erreur. Comme contrainte centrale, son constructeur est spécifié comme étant noexcept, exception safe et thread-safe, ce qui garantit une instanciation sans erreur même dans des contextes d'exécution concurrents. Les instances non traitées doivent être évitées car elles entraînent l'arrêt immédiat du programme.

plus ›

Contexte

La classe ara::diag::DiagReportingException constitue la classe d'exception centrale pour les opérations de notification et de rapport au sein du cluster fonctionnel Diagnostics (AUTOSAR_AP_SWS_Diagnostics §8.11.8 « Class: DiagReportingException »). Elle est définie comme une spécialisation publique de ara::core::Exception et représente des états d'erreur spécifiques survenant durant l'interaction avec des classes de diagnostic [SWS_DM_00987]. Dans une application AUTOSAR Adaptive, l'exception sert de lien entre les services de diagnostic internes et le logiciel d'application appelant : si une erreur se produit pendant une notification de diagnostic, DiagReportingException encapsule cet état et le transmet de façon synchrone à l'appelant via la pile d'appels. Les partenaires d'interaction principaux incluent les classes d'API liées au diagnostic du module diag, qui instancient et déclenchent l'exception en cas d'erreur, ainsi que les routines de traitement d'erreurs de niveau supérieur de l'application, qui interceptent et traitent l'erreur de diagnostic.

Cycle de vie

L'instanciation de ara::diag::DiagReportingException s'effectue explicitement par la transmission d'un code d'erreur de type ara::core::ErrorCode au constructeur [SWS_DM_00988]. La déclaration du constructeur en tant que explicit empêche les conversions implicites de codes d'erreur en objets d'exception et garantit que les instances d'exception sont toujours créées délibérément [SWS_DM_00988].

Le constructeur étant doté de la spécification noexcept, il est garanti qu'aucune autre exception ne peut survenir lors de la création même de l'objet [SWS_DM_00988]. Cela est essentiel pour les chemins d'erreur afin d'empêcher une cascade d'exceptions pendant le traitement des erreurs. De plus, le processus de construction est explicitement classé comme sûr vis-à-vis des exceptions (exception safe) et sûr vis-à-vis des threads (thread-safe) [SWS_DM_00988]. Plusieurs threads peuvent ainsi créer des objets d'exception distincts en parallèle et sans blocage mutuel.

Le cycle de vie de l'exception est lié au déroulement de pile (stack unwinding) du C++ : après sa création sur la pile d'appels, l'objet est propagé au bloc catch compétent par le mécanisme throw. La durée de vie de l'objet prend fin en quittant le gestionnaire d'exceptions, et les ressources allouées sont automatiquement libérées.

Parcours d'utilisation

Le chemin d'utilisation nominal commence dès qu'une notification ou une opération de diagnostic échoue au sein de l'Adaptive Platform. Dans le déroulement typique, la classe de diagnostic exécutante détecte une condition non autorisée et génère le ara::core::ErrorCode approprié. Au lieu de transmettre l'erreur uniquement comme valeur de retour, un objet de type ara::diag::DiagReportingException est construit et levé dans le chemin d'exception synchrone [SWS_DM_00987].

Diagramme de séquence : Déroulement typique de la création d'exceptions et du traitement d'erreurs avec DiagReportingException. Sources : [SWS_DM_00987], [SWS_DM_00988], AUTOSAR_AP_SWS_Diagnostics §8.11.8 « Class: DiagReportingException ».

Du côté du récepteur, la logique applicative intercepte l'exception. Cela se fait de préférence par référence à des objets constants (const ara::diag::DiagReportingException& ou de manière polymorphe via const ara::core::Exception&). Ensuite, le gestionnaire extrait le ara::core::ErrorCode intégré afin de déterminer la cause exacte de l'erreur et d'engager des mesures de rétablissement adaptées à la situation.

Scénarios d'erreur

Les scénarios d'erreur liés à ara::diag::DiagReportingException concernent principalement l'interprétation des données d'erreur transmises et l'absence d'un traitement d'exception approprié.

Le constructeur exige impérativement un ara::core::ErrorCode valide [SWS_DM_00988]. En raison de l'inclusion du fichier d'en-tête ara/diag/diag_error_domain.h [SWS_DM_00988], le code d'erreur transmis devrait provenir principalement du domaine d'erreur de diagnostic spécifique. Question Q-cb8a197542857807 (ouverte) Un scénario d'erreur majeur dans l'architecture applicative réside dans l'interception incomplète de l'exception : si un DiagReportingException levé n'est pas traité le long de la pile d'appels par un bloc catch adéquat, cela conduit inévitablement à l'appel de std::terminate et donc au plantage du processus de plateforme concerné. Comme le constructeur lui-même est déclaré noexcept [SWS_DM_00988], l'instanciation de l'exception ne peut pas échouer en raison d'un manque de ressources internes. Les développeurs doivent donc s'assurer que les composants appelants sont préparés à l'occurrence de DiagReportingException, en particulier lorsque des API signalant les erreurs par des exceptions plutôt que par ara::core::Result sont utilisées.