class ara::per::PerErrorDomain

Class ara::per::PerErrorDomain defines the error domain for the Persistency module and links error codes with descriptive messages as well as exception types [SWS_PER_00411]. Via thread-safe interfaces, it enables querying the domain name and resolving error descriptions for concrete error values. When required, it converts errors into C++ exceptions via ThrowAsException() [SWS_PER_00350]. If exceptions are disabled in the compiler toolchain, this throwing function is not available, so error checking must be purely return-value-based.

more ›

Context

Class ara::per::PerErrorDomain defines the specific error domain for the Persistency module (Persistency) within the AUTOSAR Adaptive Platform. It inherits from the base type definition ara::core::ErrorDomain and is declared as final, thereby forming the basis for typed error handling and error mapping of all persistency-related operations. Via standardized type aliases Errc [SWS_PER_00411] for the underlying error code enumeration PerErrc as well as Exception [SWS_PER_00412] for the module-specific exception base class PerException, the class links numeric error values, descriptive error messages, and concrete C++ exception objects. In the platform architecture, the error domain interacts closely with the Persistency services, the calling functional clusters, and the generic error and result structures from ara::core.

Lifecycle

An instance is created via the default constructor PerErrorDomain() [SWS_PER_00313]. This constructor is declared as noexcept, fully exception-safe (exception safe), and thread-safe (thread-safe). Interpretation: The instance of PerErrorDomain is likely to be managed typically as a long-lived or global object to ensure consistent domain comparisons and type resolutions for persistence errors throughout operation. Question Q-5d90982fddec40a7 (open) Since all querying operations of the class are likewise classified as thread-safe, multiple threads can access the same domain instance in parallel without requiring additional synchronization mechanisms at the caller level.

Usage Path

A typical usage path comprises identifying the domain, querying comprehensible diagnostic information, and optionally throwing exceptions upon errors occurring in the Persistency module. First, member function Name() returns the unique identifier of the error domain as a string [SWS_PER_00314]; it is specified as noexcept, exception safe, and thread-safe. If an error occurs during a Persistency operation, its numeric error value is resolved via Message() [SWS_PER_00315]. This method accepts the numeric error code of type CodeType and returns the associated error message as a pointer to constant char (const char *), likewise under the guarantee of complete exception safety and thread safety.

If an error state is to be converted into a C++ exception, function ThrowAsException() is used [SWS_PER_00350]. The following sequence illustrates the interaction during error querying and exception throwing:

Sequence diagram: Typical flow of error checking, text querying, and exception throwing via PerErrorDomain. Sources: [SWS_PER_00314], [SWS_PER_00315], [SWS_PER_00350].

Error Scenarios

In practical use of ara::per::PerErrorDomain, developers must take into account the varying guarantees regarding error handling and exception safety. While the querying interfaces Name() [SWS_PER_00314] and Message() [SWS_PER_00315] are strictly declared as noexcept and classified as exception-safe, the member function ThrowAsException() is considered not exception-safe (not exception safe) [SWS_PER_00350]. This behavior is semantically justified because the purpose of the function consists in throwing an exception corresponding to the error code in a controlled manner (noexcept(false)).

An essential constraint concerns platforms or build configurations without enabled C++ exceptions: if exception handling is disabled in the compiler, ThrowAsException() does not participate in overload resolution according to [SWS_PER_00350]. In such environments, the application software must fall back on evaluating error codes via the provided aliases Errc [SWS_PER_00411] and textual descriptions of Message() [SWS_PER_00315] instead of catching exception objects of type Exception [SWS_PER_00412].