Ansicht
Dokumentation

ABENHANDL_PROP_EXCEPT_GUIDL - HANDL PROP EXCEPT GUIDL

BAL_S_LOG - Application Log: Log header data   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Ausnahmen behandeln und propagieren

Tritt eine klassenbasierte Ausnahme auf, wird diese automatisch so lange durch die Aufrufschichten propagiert, bis die Ausnahme behandelt oder eine Schnittstelle verletzt wird:

• Tritt die Ausnahme in einem TRY-Block auf, wird nach einem passenden CATCH-Block gesucht, der sie behandelt.

• Wenn bei der Suche nach einem Behandler der Kontext einer Prozedur verlassen wird, wird deren Schnittstelle überprüft. Nur dort deklarierte Ausnahmen können aus der Prozedur heraus propagiert werden. Ausnahmen der Kategorien CX_STATIC_CHECK und CX_DYNAMIC_CHECK müssen explizit mit RAISING deklariert sein, Ausnahmen der Kategorie CX_NO_CHECK sind implizit immer deklariert (dürfen aber auch explizit deklariert werden). Bei Verletzung der Schnittstelle wird an der Aufrufstelle der Prozedur die vordefinierte Ausnahme CX_SY_NO_HANDLER ausgelöst, wobei in deren Attribut PREVIOUS eine Referenz auf die ursprüngliche Ausnahme hinterlegt wird.

Wird in keiner der beteiligten TRY-Kontrollstrukturen ein Behandler gefunden oder tritt die Ausnahme außerhalb einer TRY-Kontrollstruktur auf, kommt es an der Auslösestelle der Ausnahme zu einem Laufzeitfehler. Der Kurzdump des Laufzeitfehlers enthält den Namen der Ausnahmeklasse und den Ausnahmetext.

Ausnahmen gezielt abfangen oder geeignet weiterleiten

Fangen Sie nur die Ausnahmen ab, die Sie im aktuellen Kontext auch sinnvoll behandeln können. Bei der Weiterleitung von Ausnahmen aus darunterliegenden Softwareschichten sollen diese auf entsprechende Ausnahmen der aktuellen Softwareschicht abgebildet werden.

Beim Aufruf einer Prozedur, deren Schnittstelle klassenbasierte Ausnahmen umfasst, muss für jede dieser Ausnahmen entschieden werden, ob sie an dieser Stelle behandelt werden kann oder zum eigenen Aufrufer weitergeleitet werden soll. Ausnahmen, die auf der aktuellen Aufrufebene nicht sinnvoll behandelt werden können, müssen zur darüberliegenden Aufrufebene weitergeleitet werden. Dies geschieht bei klassenbasierten Ausnahmen implizit durch den Verzicht auf eine Behandlung innerhalb der aktuellen Aufrufebene. Nur in Fällen, in denen man sich absolut sicher ist, dass weder ein Abfangen noch ein Weiterleiten etwas nutzen, sollte man es an dieser Stelle zu einem Laufzeitfehler kommen lassen.

Bei der Weiterleitung von Ausnahmen entlang der Aufrufkette über mehrere Ebenen bewegen diese sich im Allgemeinen von tiefer liegenden, technischen Schichten hin zu höher liegenden, abstrakteren und anwendungsnäheren Schichten. Die Aufrufer in diesen höheren Schichten haben nicht unbedingt Kenntnis von den Implementierungsdetails in den unteren Schichten und können daher Ausnahmen von dort nicht sinnvoll interpretieren. Aus diesem Grund sollen Ausnahmen die Grenzen zwischen Softwareschichten nicht einfach überschreiten, sondern dort auf geeignete Ausnahmen mit einem höheren Abstraktionsgrad abgebildet werden.

Für die Weiterleitung zwischen Softwareschichten ist es daher empfehlenswert, sich nicht auf die automatische Propagierung zu verlassen, sondern die ursprüngliche Ausnahme abzufangen und durch das Auslösen einer neuen Ausnahme eine Abbildung auf eine Ausnahme des aktuellen Kontextes vorzunehmen (dabei sollte der Zusammenhang zwischen ursprünglich ausgelöster und am Ende entstandener Ausnahme durch Verwendung des PREVIOUS-Attributes erhalten werden). Auf diese Weise wird sichergestellt, dass der Aufrufer einer Prozedur nur solche Ausnahmen erhält, die er auch verstehen kann. Aus Gründen der Paketkapselung wird ein solches Vorgehen ohnehin erforderlich sein, wenn Ausnahmen zwischen Softwareschichten weitergegeben werden sollen.

Hinweis

Durch das Weiterleiten in höhere Softwareschichten findet somit in der Regel eine Generalisierung von vorher sehr speziellen Ausnahmen statt. Je genereller eine Ausnahme ist, desto höher ist deshalb in der Regel auch die Softwareschicht, in der sie behandelt wird. Insbesondere sollten die generellsten aller möglichen Ausnahmen, nämlich die vom Typ CX_STATIC_CHECK, CX_DYNAMIC_CHECK, CX_NO_CHECK, oder CX_ROOT, höchstens in den obersten Softwareschichten abgefangen werden, und das auch nur dann, wenn ein Laufzeitfehler unter allen Umständen vermieden werden muss.

General Material Data   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 4798 Date: 20240523 Time: 173634     sap01-206 ( 116 ms )