Die Anweisung TRY leitet eine Kontrollstruktur mit mehreren Anweisungsblöcken
ein. Der erste Anweisungsblock try_block wird immer durchlaufen, während zu genau einem der übrigen Anweisungsblöcke nur dann verzweigt wird, wenn eine
klassenbasierte Ausnahme im try_block auftritt.
Eine TRY-Kontrollstruktur definiert folgende Anweisungsblöcke:
einen TRY-Block try_block direkt hinter der Anweisung
TRY. Der TRY-Block definiert einen geschützten
Bereich, dessen klassenbasierte Ausnahmen in den nachfolgenden CATCH-Blöcken
behandelt werden können. Wenn im TRY-Block keine Ausnahme auftritt
und sein Ende erreicht wird, wird die Verarbeitung hinter ENDTRY fortgesetzt.
Tritt im TRY-Block eine klassenbasierte Ausnahme auf, sucht das System nach einem Ausnahmebehandler in der gleichen oder einer äußeren TRY-Kontrollstruktur (siehe
Systemverhalten).
einen oder mehrere optionale CATCH-Blöcke catch_block
für die Ausnahmebehandlung jeweils direkt hinter einer
CATCH-Anweisung. Wird das Ende eines CATCH-Blocks erreicht ohne
dass er vorzeitig verlassen wird, wird die Verarbeitung hinter ENDTRY fortgesetzt.
In einem CATCH-Block können die speziellen Anweisungen RETRY und RESUME aufgeführt werden, um das Verhalten der Ausnahmebehandlung zu steuern.
einen optionalen CLEANUP-Block cleanup_block für
Aufräumarbeiten direkt hinter der Anweisung CLEANUP.
Alle Anweisungsblöcke einer TRY-Kontrollstruktur können beliebige Kontrollstrukturen, insbesondere weitere TRY-Kontrollstrukturen, enthalten.
Da aus statischen Konstruktoren und
Ereignisbehandlern keine Ausnahmen propagiert
werden dürfen (außer solche der Kategorie CX_NO_CHECK aus Ereignisbehandlern), müssen sie dort immer lokal behandelt werden.
Beispiel
Division durch Null in einem TRY-Block. Die fällige Ausnahme wird mit CATCH abgefangen.