Ausnahmekette als Fehlersammlung: Sinnvoll oder nicht?
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Hallo liebe ABAP-Gemeinde,
ich habe vor kurzem eine Prüfmethode geschrieben, in der ich mittels einer wiederaufsetzbaren Exception alle fehlgeschlagenen Prüfungen in einer Ausnahmekette gesammelt habe, um diese am Ende auszugeben.
Das ganze funktioniert folgendermaßen:
Die zum Schluss ausgelöste Exception wird dann in einer höherliegenden Aufrufebene abgefangen. Dabei werden dann alle Ausnahmetexte erfasst:
Nun meine Frage dazu: stellt dieses Verfahren eine gültige, programmiertechnisch sinnvolle und robuste Vorgehensweise dar?
Oder gibt es dabei irgendwelche Stolpersteine? Missbrauche ich damit eventuell sogar das ganze Konzept der Ausnahmeverkettung?
ich habe vor kurzem eine Prüfmethode geschrieben, in der ich mittels einer wiederaufsetzbaren Exception alle fehlgeschlagenen Prüfungen in einer Ausnahmekette gesammelt habe, um diese am Ende auszugeben.
Das ganze funktioniert folgendermaßen:
Code: Alles auswählen.
* Zuerst werden diverse DDIC-Objekte auf Existenz geprüft und jeweils ein Flag gesetzt
* (den entsprechenden Code habe ich hier mal weggelassen, der tut nichts zur Sache)
* ......
* ......
* ......
* Ausnahmekette aus fehlgeschlagenen Prüfungen bilden
* Hier werden die einzelnen Flags innerhalb eines TRY-CATCH-Blocks geprüft und bei
* negativen Ergebnissen jeweils eine wiederaufsetzbare Exception ausgelöst, durch die
* Verwendung des Attributs PREVIOUS wird hierbei eine Ausnahmekette gebildet
TRY.
IF lv_cls_exists = abap_false.
RAISE RESUMABLE EXCEPTION TYPE zcx_qpp_error
EXPORTING
textid = zcx_qpp_error=>objtyp_class_not_found
previous = lo_exception
...
ENDIF.
IF lv_rep_exists = abap_false.
RAISE RESUMABLE EXCEPTION TYPE zcx_qpp_error
EXPORTING
textid = zcx_qpp_error=>objtyp_fugr_not_found
previous = lo_exception
...
ENDIF.
IF lv_dyn_exists = abap_false.
RAISE RESUMABLE EXCEPTION TYPE zcx_qpp_error
EXPORTING
textid = zcx_qpp_error=>objtyp_dynpro_not_found
previous = lo_exception
...
ENDIF.
IF lv_cnt_exists = abap_false.
RAISE RESUMABLE EXCEPTION TYPE zcx_qpp_error
EXPORTING
textid = zcx_qpp_error=>objtyp_container_not_found
previous = lo_exception
...
ENDIF.
CATCH BEFORE UNWIND zcx_qpp_error INTO lo_exception.
IF lo_exception->is_resumable = abap_true.
RESUME.
ENDIF.
ENDTRY.
* Wenn Prüfung Fehler ergeben hat, finale Ausnahme auslösen
* und vorhergehende Ausnahmekette mitgeben
IF lo_exception IS BOUND.
RAISE EXCEPTION TYPE zcx_qpp_error
EXPORTING
textid = zcx_qpp_error=>objtyp_check_failed
previous = lo_exception
objtyp = iv_objtyp.
ENDIF.
Code: Alles auswählen.
WHILE lo_cx IS BOUND.
INSERT INITIAL LINE INTO lt_messages ASSIGNING <fs_message> INDEX 1.
<fs_message>-text = lo_cx->get_text( ).
lo_cx = lo_cx->previous.
ENDWHILE.
Nun meine Frage dazu: stellt dieses Verfahren eine gültige, programmiertechnisch sinnvolle und robuste Vorgehensweise dar?
Oder gibt es dabei irgendwelche Stolpersteine? Missbrauche ich damit eventuell sogar das ganze Konzept der Ausnahmeverkettung?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hmmm...
Ich glaub eher, dass das von dir gewünschte Verhalten so nicht abbildbar ist.
Mit PREVIOUS kann man NICHT allgemein auf "vorherige" Fehler die in der Applikation passiert sind zugreifen sondern nur jene die kausal zusammenhängen.
Die PREVIOUS-Excpetions haben also nicht das von dir erwartete Verhalten.
Es geht dabei darum einen "allgemeinen" Ausnahmefehler weiter zu spezifizieren.
Beispiel:
Irgendwo in der Applikation wird ein CX_SY_ASSIGN_ERROR ausgelöst. Im CATCH-Block der dies abfängt, weiß man aber dass dadurch auch ein anderer (Applikations-)Fehler bedingt ist: ZCX_INIT_FAILED. Dann bezieht sich der PREVIOUS auf den Systemfehler und der eigentliche Fehler der nach außen weitergeben wird ist ein Applikationsfehler.
RESUME und RESUMABLE dienen dazu einen Fehler nach außen zu probagieren und nach dessen Abarbeitung trotzdem die Verarbeitung fortzusetzen.
Es muss also sichergestellt sein, dass nach dem Fehler kein undefinierter Zustand vorherscht.
Bestes Beispiel ist die Prüfung von mehreren Benutzereingaben mittels Exception-Handling.
Ohne RESUMEABLE würde nur solange geprüft werden, bis eine fehlerhafte Eingabe entdeckt wurde. Wenn dannach noch weitere Felder fehlerhaft sind würde der Benutzer dies erst sehen, wenn er den aktuellen Fehler korrigiert hat.
Mit RESUMEABLE sieht er sofort eine vollständig Liste all seiner Fehler und kann sie in einem Schritt abarbeiten.
(Natürlich nur mit entsprechendem Errohandling, dass die Exceptions sammelt und an einer zentralen Stelle ausgibt.)
lg ADT
EDIT:
In deinem Coding-Beispiel würde der CATCH der Reihe nach alle Fehler, die im TRY passieren abfangen und NICHT nach außen weiter geben. Denn der erster CATCH im Aufrufstack der zutrifft ist für die Fehlerverarbeitung zuständig. Durch das RESUME wird nur die Verarbeitung nach dem RAISE EXCEPTION wieder aufgenommen. Am Ende steht also in LO_EXCEPTION nur der letzte Fehler drinnen der aufgetreten ist. Die anderen Fehler sind nicht mehr bekannt und wurden auch nicht an eine höhere Verarbeitung weitergereicht.
Ich glaub eher, dass das von dir gewünschte Verhalten so nicht abbildbar ist.
Mit PREVIOUS kann man NICHT allgemein auf "vorherige" Fehler die in der Applikation passiert sind zugreifen sondern nur jene die kausal zusammenhängen.
Die PREVIOUS-Excpetions haben also nicht das von dir erwartete Verhalten.
Es geht dabei darum einen "allgemeinen" Ausnahmefehler weiter zu spezifizieren.
Beispiel:
Irgendwo in der Applikation wird ein CX_SY_ASSIGN_ERROR ausgelöst. Im CATCH-Block der dies abfängt, weiß man aber dass dadurch auch ein anderer (Applikations-)Fehler bedingt ist: ZCX_INIT_FAILED. Dann bezieht sich der PREVIOUS auf den Systemfehler und der eigentliche Fehler der nach außen weitergeben wird ist ein Applikationsfehler.
Code: Alles auswählen.
try.
* Hier können verschiedene Fehler auftreten.
catch cx_root into lx_root.
raise exception type ZCX_INIT_FAILED "<-- Eigener Fehler im Rahmen der Applikation
previous = lx_root.
endtry.Es muss also sichergestellt sein, dass nach dem Fehler kein undefinierter Zustand vorherscht.
Bestes Beispiel ist die Prüfung von mehreren Benutzereingaben mittels Exception-Handling.
Ohne RESUMEABLE würde nur solange geprüft werden, bis eine fehlerhafte Eingabe entdeckt wurde. Wenn dannach noch weitere Felder fehlerhaft sind würde der Benutzer dies erst sehen, wenn er den aktuellen Fehler korrigiert hat.
Mit RESUMEABLE sieht er sofort eine vollständig Liste all seiner Fehler und kann sie in einem Schritt abarbeiten.
(Natürlich nur mit entsprechendem Errohandling, dass die Exceptions sammelt und an einer zentralen Stelle ausgibt.)
lg ADT
EDIT:
In deinem Coding-Beispiel würde der CATCH der Reihe nach alle Fehler, die im TRY passieren abfangen und NICHT nach außen weiter geben. Denn der erster CATCH im Aufrufstack der zutrifft ist für die Fehlerverarbeitung zuständig. Durch das RESUME wird nur die Verarbeitung nach dem RAISE EXCEPTION wieder aufgenommen. Am Ende steht also in LO_EXCEPTION nur der letzte Fehler drinnen der aufgetreten ist. Die anderen Fehler sind nicht mehr bekannt und wurden auch nicht an eine höhere Verarbeitung weitergereicht.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Okay... Ich lass meinen vorherigen Post mal so stehen.
Wollte gerade einen besseren Vorschlag anhand deines Codings schreiben und hab da erst kapiert was du eigentlich bezweckst.
Interessante Vorgehensweise: LO_EXCEPTION zeigt so immer auf den vorherigen Fehler und wird einfach in die nächste Exception mitaufgenommen.
Ich weiß jetzt nicht wie der Standard das darstellen würde (ST22)
Aber was ich weiß, soll mit PREVIOUS (wie ich vorher schon erwähnt hab) eigentlich ein kausaler Zusammenhang zwischen den Fehlern dargestellt werden.
z.B. in deinem Coding: Wenn der Report nicht existiert, existiert auch nicht das Dynpro.
Also zeigt der PREVIOUS von ZCX_QPP_ERROR(objtyp_dynpro_not_found) auf ZCX_QPP_ERROR(objtyp_fugr_not_found)
ZCX_QPP_ERROR(objtyp_class_not_found) hat logisch mit den beiden anderen nichts zu tun, denn eine Klasse kann auch ohne Programm und umgekehrt existieren. Nur deine Applikation verlangt nach beidem; Klasse und Fugr+Dynpro+Container
Das wären dann nach meinem Verständnis zwei Exceptions.
Wollte gerade einen besseren Vorschlag anhand deines Codings schreiben und hab da erst kapiert was du eigentlich bezweckst.
Interessante Vorgehensweise: LO_EXCEPTION zeigt so immer auf den vorherigen Fehler und wird einfach in die nächste Exception mitaufgenommen.
Ich weiß jetzt nicht wie der Standard das darstellen würde (ST22)
Aber was ich weiß, soll mit PREVIOUS (wie ich vorher schon erwähnt hab) eigentlich ein kausaler Zusammenhang zwischen den Fehlern dargestellt werden.
z.B. in deinem Coding: Wenn der Report nicht existiert, existiert auch nicht das Dynpro.
Also zeigt der PREVIOUS von ZCX_QPP_ERROR(objtyp_dynpro_not_found) auf ZCX_QPP_ERROR(objtyp_fugr_not_found)
ZCX_QPP_ERROR(objtyp_class_not_found) hat logisch mit den beiden anderen nichts zu tun, denn eine Klasse kann auch ohne Programm und umgekehrt existieren. Nur deine Applikation verlangt nach beidem; Klasse und Fugr+Dynpro+Container
Das wären dann nach meinem Verständnis zwei Exceptions.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
DUTZMIC
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Letztere Interpretation stimmt mit meiner Absicht überein
Also nochmal zur Klarstellung: das ganz soll eine zwar umständlichere, dafür aber auch detailliertere und besser behandelbare Alternative zur Sammlung der Fehler in einer Nachrichtentabelle oder Flag-Struktur als Exportparameter der umgebenden Methode darstellen.
Der kausale Zusammenhang ist dabei zwischen den Fehlern, wie du schon sagtest, eben nicht vorhanden, was wohl der Intention des PREVIOUS-Attributs widerspricht. Das ist aber das einzige Manko, das ich an dieser Vorgehensweise erkennen kann.
Wenn sich die Nachteile auf diese einzige Tatsache beschränken, würde ich diese Methode nämlich auch weiterhin bei ähnlichen Anwendungsfällen nutzen.
Normalerweise missfällt es mir ja, gängige Programmiertechniken zu missbrauchen oder ihrem Zweck zu entfremden, aber hierbei sehe ich halt keine gravierenden Kehrseiten
Zumal die Verwendung einer einzelnen Ausnahmeklasse (ZCX_QPP_ERROR) als Container für alle in der Applikation möglichen Exceptions (dargestellt durch die Ausnahmetexte) wohl auch schon den Konventionen widerspricht, oder irre ich mich da?
Also nochmal zur Klarstellung: das ganz soll eine zwar umständlichere, dafür aber auch detailliertere und besser behandelbare Alternative zur Sammlung der Fehler in einer Nachrichtentabelle oder Flag-Struktur als Exportparameter der umgebenden Methode darstellen.
Der kausale Zusammenhang ist dabei zwischen den Fehlern, wie du schon sagtest, eben nicht vorhanden, was wohl der Intention des PREVIOUS-Attributs widerspricht. Das ist aber das einzige Manko, das ich an dieser Vorgehensweise erkennen kann.
Wenn sich die Nachteile auf diese einzige Tatsache beschränken, würde ich diese Methode nämlich auch weiterhin bei ähnlichen Anwendungsfällen nutzen.
Normalerweise missfällt es mir ja, gängige Programmiertechniken zu missbrauchen oder ihrem Zweck zu entfremden, aber hierbei sehe ich halt keine gravierenden Kehrseiten
Zumal die Verwendung einer einzelnen Ausnahmeklasse (ZCX_QPP_ERROR) als Container für alle in der Applikation möglichen Exceptions (dargestellt durch die Ausnahmetexte) wohl auch schon den Konventionen widerspricht, oder irre ich mich da?
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Ich verwend das (leider) auch oft soDUTZMIC hat geschrieben:Zumal die Verwendung einer einzelnen Ausnahmeklasse (ZCX_QPP_ERROR) als Container für alle in der Applikation möglichen Exceptions (dargestellt durch die Ausnahmetexte) wohl auch schon den Konventionen widerspricht, oder irre ich mich da?
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
DUTZMIC
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Auch wenn es schon etwas her ist :
Genau genommen ist es doch SAP Standard. Da alle Applikationen von CX_ROOT erben. Ich sehe da nirgends einen Konzeptverstoss.a-dead-trousers hat geschrieben: Ich verwend das (leider) auch oft so
"Code lügt nicht ^^"
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1529
Views
Views
8
Antw.
Antw.
4580
Views
Views
Orgmanagement Transportieren - Sinnvoll?
von SaskuAc » 27.11.2019 10:48 • Verfasst in Human Resources
von SaskuAc » 27.11.2019 10:48 • Verfasst in Human Resources
2
Antw.
Antw.
1774
Views
Views
SAP Flatrate - welche Kurse sind sinnvoll?
von Cargo2 » 12.02.2020 09:26 • Verfasst in SAP - Allgemeines
von Cargo2 » 12.02.2020 09:26 • Verfasst in SAP - Allgemeines
10
Antw.
Antw.
1295
Views
Views
Massenverarbeitung mit vielen Batchjobs, wie Ressourcen sinnvoll verwalten?
von Romaniac » 02.11.2022 10:18 • Verfasst in ABAP® Core
von Romaniac » 02.11.2022 10:18 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.