class ara::crypto::CryptoException

The class ara::crypto::CryptoException functions in the AUTOSAR Adaptive Platform as a specialized exception for signaling cryptographic errors to calling applications. It derives from ara::core::Exception and is explicitly instantiated with an ara::core::ErrorCode upon failed operations [SWS_CRYPT_19906]. Specified as noexcept and thread-safe, reliable exception generation is guaranteed even in concurrent environments without secondary errors [SWS_CRYPT_19906]. Applications must safeguard cryptographic calls accordingly to avoid unhandled exceptions and program terminations.

more ›

Context

The class ara::crypto::CryptoException defines the central exception type for error states within the crypto module of the AUTOSAR Adaptive Platform. As a specialization of the standard exception class ara::core::Exception, it bridges the gap between the error-code-based return mechanism primarily used in the platform and classic C++ exception handling mechanisms. It is used in system architectures where cryptographic operations fail and this error condition needs to be propagated across the call stack as an exception. Primary interaction partners include cryptographic function modules and services that throw exceptions upon unforeseen errors or explicit checks, as well as higher-level application components that trigger cryptographic operations such as encryption, signature verification, or key management and catch potential errors. By being anchored in the platform's common error domain concept, ara::crypto::CryptoException ensures that cryptographic errors are reported to the application logic consistently and in a typed manner.

Lifecycle

An object of ara::crypto::CryptoException is created deterministically by passing an error code of type ara::core::ErrorCode to the constructor [SWS_CRYPT_19906]. This constructor is declared as explicit to prevent implicit type conversions from error codes, and has the specification noexcept [SWS_CRYPT_19906]. The latter guarantees that no further exceptions can be thrown during the construction of the exception itself, which substantially increases the exception safety and operational reliability of the crypto subsystem. According to the specification, the implementation is classified as thread-safe [SWS_CRYPT_19906], so instances can also be instantiated and processed reliably in concurrent execution environments. Regarding ownership semantics, the exception is typically thrown by value and caught by const reference in the catching block. Since the class manages no dynamic resources beyond the error code, its lifecycle normally ends upon exiting the handling catch block (interpretation). Question (open)

Usage Path

The regular usage path begins within a cryptographic operation when an error condition occurs that cannot be resolved locally. The module identifies the cause of the error based on the cryptographic error domain from header file ara/crypto/common/crypto_error_domain.h and creates a corresponding ara::core::ErrorCode [SWS_CRYPT_19906]. Subsequently, an instance of ara::crypto::CryptoException is instantiated with this error code [SWS_CRYPT_19906] and signaled via a throw statement. On the application side, the calling component specifically catches the exception via catch (const ara::crypto::CryptoException& e). Alternatively, the inheritance hierarchy also permits polymorphic catching as a generic ara::core::Exception. By querying the contained ara::core::ErrorCode, the application can subsequently analyze the specific cryptographic error cause and take appropriate countermeasures.

Sequence diagram: Typical flow of error handling and exception throwing during cryptographic operations. Sources: [SWS_CRYPT_19906]

Error Scenarios

Since ara::crypto::CryptoException itself constitutes the vehicle for error signaling, the primary focus in error scenarios is on the robustness of exception generation. Ensuring exception safety, thread safety, and the noexcept guarantee of the constructor prevents secondary exceptions from occurring during already active error handling [SWS_CRYPT_19906]. A potential error scenario in application logic is that a passed ara::core::ErrorCode encapsulates unexpected or non-cryptographic error domains; presumably, the exception still processes the error code neutrally and transports it unchanged to the handler (interpretation). Question Q-0bb3376f547ce024 (open) Another risk at the system level is failure to catch the exception, which in a C++ runtime environment would lead to a call to std::terminate. Therefore, calling components using APIs without error-code-based return must consistently safeguard cryptographic calls with appropriate catch blocks.