class ara::diag::DiagReportingException

The exception class ara::diag::DiagReportingException serves for the synchronous signaling of error states that occur during operations within diagnostic classes of the Adaptive Platform (AUTOSAR_AP_SWS_Diagnostics §8.11.8 “Class: DiagReportingException”). It is explicitly instantiated with a specific ara::core::ErrorCode and transports it to the calling application for root cause analysis [SWS_DM_00988]. As a central constraint, its constructor is specified as noexcept, exception safe, and thread-safe, which guarantees error-free creation even in concurrent execution contexts. Unhandled instances must be avoided, as they lead to immediate program termination.

more ›

Context

The class ara::diag::DiagReportingException forms the central exception class for notification and reporting operations within the Diagnostics functional cluster (AUTOSAR_AP_SWS_Diagnostics §8.11.8 “Class: DiagReportingException”). It is defined as a public specialization of ara::core::Exception and represents specific error states that occur during interaction with diagnostic classes [SWS_DM_00987]. In an AUTOSAR Adaptive application, the exception functions as a link between internal diagnostic services and the calling application software: if an error occurs during a diagnostic report, DiagReportingException encapsulates this state and transports it synchronously via the call stack to the caller. Primary interaction partners include the diagnostic-related API classes of module diag, which instantiate and throw the exception in case of error, as well as higher-level error handling routines of the application, which catch and process the diagnostic error.

Lifecycle

Instantiation of ara::diag::DiagReportingException is performed explicitly by passing an error code of type ara::core::ErrorCode to the constructor [SWS_DM_00988]. Declaring the constructor as explicit prevents implicit conversions of error codes into exception objects and ensures that exception instances are always created deliberately [SWS_DM_00988].

Since the constructor is marked with the specification noexcept, it is guaranteed that no further exceptions can occur during object creation itself [SWS_DM_00988]. This is essential for error paths in order to prevent cascading exceptions during error handling. In addition, the construction process is explicitly classified as exception safe and thread-safe [SWS_DM_00988]. Multiple threads can thus create separate exception objects in parallel without mutual blocking.

The life cycle of the exception is tied to C++ stack unwinding: after creation on the call stack, the object is propagated to the responsible catch block via the throw mechanism. Exiting the exception handler ends the lifetime of the object, and allocated resources are automatically released.

Usage Path

The regular usage path begins as soon as a diagnostic report or operation within the Adaptive platform fails. In the typical sequence, the executing diagnostic class detects an impermissible condition and creates the appropriate ara::core::ErrorCode. Instead of merely transmitting the error as a return value, an object of type ara::diag::DiagReportingException is constructed and thrown in the synchronous exception path [SWS_DM_00987].

Sequence diagram: Typical sequence of exception creation and error handling with DiagReportingException. Sources: [SWS_DM_00987], [SWS_DM_00988], AUTOSAR_AP_SWS_Diagnostics §8.11.8 “Class: DiagReportingException”.

On the receiving side, the application logic catches the exception. This is preferably done by reference to const objects (const ara::diag::DiagReportingException& or polymorphically via const ara::core::Exception&). The handler then extracts the embedded ara::core::ErrorCode to determine the exact cause of the error and initiate context-appropriate recovery actions.

Error Scenarios

Error scenarios related to ara::diag::DiagReportingException primarily concern the interpretation of the passed error data and the failure to perform proper exception handling.

The constructor strictly requires a valid ara::core::ErrorCode [SWS_DM_00988]. By including the header file ara/diag/diag_error_domain.h [SWS_DM_00988], the passed error code is likely to originate primarily from the specific diagnostic error domain. Question Q-cb8a197542857807 (open) A primary error scenario in the application architecture lies in incomplete exception catching: if a thrown DiagReportingException along the call stack is not handled by a matching catch block, this inevitably leads to a call to std::terminate and thus to a crash of the respective platform process. Since the constructor itself is declared noexcept [SWS_DM_00988], instantiation of the exception cannot fail due to internal resource shortages. Developers must therefore ensure that calling components are prepared for the occurrence of DiagReportingException, particularly when using APIs that signal errors via exceptions instead of ara::core::Result.