Signalisiert Fehler bei Diagnoseoperationen synchron als Ausnahme mit Fehlercode an den Aufrufer.
Kontext
Die Klasse ara::diag::DiagReportingException bildet die zentrale Ausnahmeklasse für Melde- und Berichtsvorgänge innerhalb des Funktionsclusters Diagnose (AUTOSAR_AP_SWS_Diagnostics §8.11.8 „Class: DiagReportingException“). Sie ist als öffentliche Spezialisierung von ara::core::Exception definiert und repräsentiert spezifische Fehlerzustände, die während der Interaktion mit Diagnoseklassen auftreten [SWS_DM_00987]. In einer AUTOSAR-Adaptive-Anwendung fungiert die Ausnahme als Bindeglied zwischen den internen Diagnosediensten und der aufrufenden Anwendungssoftware: Tritt während einer diagnostischen Meldung ein Fehler auf, kapselt DiagReportingException diesen Zustand und transportiert ihn synchron über den Call-Stack zum Aufrufer. Zu den primären Interaktionspartnern gehören die diagnosebezogenen API-Klassen des Moduls diag, welche die Ausnahme im Fehlerfall instanziieren und auslösen, sowie übergeordnete Fehlerbehandlungsroutinen der Anwendung, die den Diagnosefehler abfangen und verarbeiten.
Lebenszyklus
Die Instanziierung von ara::diag::DiagReportingException erfolgt explizit durch die Übergabe eines Fehlercodes vom Typ ara::core::ErrorCode an den Konstruktor [SWS_DM_00988]. Die Deklaration des Konstruktors als explicit verhindert implizite Konvertierungen von Fehlercodes in Ausnahmeobjekte und stellt sicher, dass Ausnahmeinstanzen stets bewusst erzeugt werden [SWS_DM_00988].
Da der Konstruktor mit der Spezifikation noexcept versehen ist, wird garantiert, dass bei der Objekterzeugung selbst keine weiteren Ausnahmen auftreten können [SWS_DM_00988]. Dies ist für Fehlerpfade essenziell, um eine Kaskadierung von Ausnahmen während der Fehlerbehandlung zu unterbinden. Zudem ist der Konstruktionsvorgang explizit als ausnahmesicher (exception safe) und threadsicher (thread-safe) klassifiziert [SWS_DM_00988]. Mehrere Threads können somit parallel und ohne wechselseitige Blockaden separate Ausnahmeobjekte erzeugen.
Der Lebenszyklus der Ausnahme ist an das C++-Stack-Unwinding gebunden: Nach der Erzeugung auf dem Call-Stack wird das Objekt durch den throw-Mechanismus an den zuständigen catch-Block propagiert. Mit dem Verlassen des Ausnahmebehandlers endet die Lebensdauer des Objekts, und die belegten Ressourcen werden automatisch freigegeben.
Nutzungspfad
Der reguläre Nutzungspfad setzt ein, sobald eine diagnostische Meldung oder Operation innerhalb der Adaptive-Plattform fehlschlägt. Im typischen Ablauf erkennt die ausführende Diagnoseklasse eine unzulässige Bedingung und erzeugt den passenden ara::core::ErrorCode. Anstatt den Fehler lediglich als Rückgabewert zu übermitteln, wird im synchronen Ausnahmepfad ein Objekt vom Typ ara::diag::DiagReportingException konstruiert und geworfen [SWS_DM_00987].
Sequenzdiagramm: Typischer Ablauf der Ausnahmeerzeugung und Fehlerbehandlung mit DiagReportingException. Quellen: [SWS_DM_00987], [SWS_DM_00988], AUTOSAR_AP_SWS_Diagnostics §8.11.8 „Class: DiagReportingException“.
Auf Empfängerseite fängt die Applikationslogik die Ausnahme ab. Dies geschieht vorzugsweise per Referenz auf konstante Objekte (const ara::diag::DiagReportingException& oder polymorph über const ara::core::Exception&). Anschließend extrahiert der Handler den eingebetteten ara::core::ErrorCode, um die genaue Fehlerursache zu ermitteln und situationsgerechte Wiederherstellungsmaßnahmen einzuleiten.
Fehlerszenarien
Fehlerszenarien im Zusammenhang mit ara::diag::DiagReportingException betreffen vor allem die Interpretation der übergebenen Fehlerdaten und das Ausbleiben einer ordnungsgemäßen Ausnahmebehandlung.
Der Konstruktor fordert zwingend einen gültigen ara::core::ErrorCode [SWS_DM_00988]. Durch die Einbindung der Header-Datei ara/diag/diag_error_domain.h [SWS_DM_00988] dürfte der übergebene Fehlercode primär der spezifischen Diagnose-Fehlerdomäne entstammen. Frage Q-cb8a197542857807 (offen) Ein primäres Fehlerszenario in der Anwendungsarchitektur liegt im unvollständigen Abfangen der Ausnahme: Wird eine geworfene DiagReportingException entlang des Call-Stacks nicht durch einen passenden catch-Block behandelt, führt dies unweigerlich zum Aufruf von std::terminate und damit zum Absturz des betreffenden Plattform-Prozesses. Da der Konstruktor selbst noexcept deklariert ist [SWS_DM_00988], kann die Instanziierung der Ausnahme nicht an internem Ressourcenmangel scheitern. Entwickler müssen daher sicherstellen, dass aufrufende Komponenten auf das Auftreten von DiagReportingException vorbereitet sind, insbesondere wenn APIs genutzt werden, die Fehler über Ausnahmen anstelle von ara::core::Result signalisieren.
Dieser Leitfaden wurde durch eine KI auf Basis der Spezifikation AUTOSAR Adaptive R25-11 generiert.
gemini-3.8-flash-medium· 2026-10-13