class ara::com::ComErrorDomain

The class ara::com::ComErrorDomain represents the communication error domain for identifying general, non-interface-specific errors in the ara::com API ([SWS_CM_11265]). It provides error descriptions for error codes such as ComErrc::kCommunicationFailure and enables querying them via Message() or converting them into an exception using ThrowAsException() ([SWS_CM_11332]). Because its default constructor is deleted, it acts as a stateless, thread-safe domain instance for the error-carrying ara::core::Result.

more ›

Context

The class ara::com::ComErrorDomain represents the standardized communication error domain of the Adaptive Platform for the Communication Management functional cluster (SWS CommunicationManagement p. 439). It derives from the base class ara::core::ErrorDomain and defines the semantic context for general errors that may occur during method calls or data transmissions, but are not specific to a single ServiceInterface ([SWS_CM_11265]). In the error architecture of ara::com, it systematically distinguishes general communication disruptions from E2E monitoring errors as well as application-specific service errors (SWS CommunicationManagement §7.5.22.6 “Error Related Data Types”).

Its central interaction partners include the Adaptive Application, the service and proxy implementations of the middleware, and the data types ara::core::ErrorCode and ara::core::Result of the base system (EXP ARAComAPI §4.7 “Error Handling”). For semantic type binding, the class provides the type aliases Errc for the error code enumeration ComErrc ([SWS_CM_11336]) and Exception for the associated exception class ComException ([SWS_CM_11337]).

Context diagram: Classification of ComErrorDomain into the error architecture of ara::com. Sources: [SWS_CM_11265], EXP ARAComAPI §4.7 “Error Handling”, SWS CommunicationManagement §7.5.22.6 “Error Related Data Types”

Lifecycle

As a specification class for an error domain, creation of ara::com::ComErrorDomain is prevented by the deletion of the default constructor ComErrorDomain() = delete; ([SWS_CM_11330]). Interpretation: Provision of the domain instance is presumably carried out as a static singleton via the platform, so that application components do not need to dynamically instantiate or manage the domain. Question Q-bf957a108c0a5378 (open)

The instance acts as a stateless descriptor without mutable attributes. All provided methods, such as Name() ([SWS_CM_11331]) and Message() ([SWS_CM_11332]), are declared as const noexcept. This guarantees full thread safety for concurrent error queries by parallel application and middleware threads.

Usage Path

The typical usage path comprises the detection, transmission, and evaluation of an error via the interfaces of ara::com:

1. The application initiates a service interaction, for example via the call operator of the method class operator() ([SWS_CM_00196]).
2. If the middleware detects an error during processing, such as a communication failure or an unconfigured application error ([SWS_CM_00048]), the operation SetError is called on the corresponding Promise (SWS CommunicationManagement p. 300).
3. In doing so, an ara::core::ErrorCode is constructed whose domain is set to ara::com::ComErrorDomain ([SWS_CM_11329]) and whose numerical code is set to a specific enum value such as ComErrc::kCommunicationFailure ([SWS_CM_10432]).
4. The ara::core::Future or ara::core::Result returned to the application transports the error code in the error state to the caller (EXP ARAComAPI §4.7 “Error Handling”).
5. The application checks the Result and uses the domain functions Name() ([SWS_CM_11331]) and Message() ([SWS_CM_11332]) to resolve error messages for logging or diagnostics.
6. If the application logic expects an exception and C++ exceptions are enabled, conversion into an ComException can be triggered using ThrowAsException() ([SWS_CM_11333]).

Sequence diagram: Signaling and querying a communication error via ComErrorDomain. Sources: [SWS_CM_00196], [SWS_CM_10432], [SWS_CM_11329], [SWS_CM_11332], SWS CommunicationManagement p. 300

Error Scenarios

The error concept of ara::com strictly distinguishes between recoverable errors and severe programming violations (violations or corruptions) (EXP ARAComAPI §4.7 “Error Handling”). Recoverable errors are handled via ara::core::Result and ara::core::ErrorCode, with error codes of domain ComErrorDomain being addressed via the identifier alias Errc ([SWS_CM_11336]).

If, for example, a transmission interruption occurs during a remote call, the system reports ComErrc::kCommunicationFailure ([SWS_CM_10432]). In the event of an unconfigured application error, the middleware aborts the call and likewise sets a corresponding error code of the domain ([SWS_CM_00048], SWS CommunicationManagement p. 300).

If an error code is to be thrown as an exception, ThrowAsException() instantiates an exception of type ComException ([SWS_CM_11337]) and throws it ([SWS_CM_11333]). This method is not exception-safe (not exception safe) and, according to the specification, does not participate in overload resolution when C++ exceptions are disabled ([SWS_CM_11333]). Non-recoverable system violations, on the other hand, lead directly to a platform abort and are not handled via ComErrorDomain (EXP ARAComAPI §4.7 “Error Handling”).