Exceptions
Hallo zusammen!
ich ärgere mich gerade mit EXCEPTION-Klassen herum...
Ich frage mich, ob es möglich ist, die übergebenen Werte bei Auslösen der Exception noch irgendwie auszuwerten?!
Beispiel:
Ich habe eine Ausnahmeklasse definiert und den TEXT "FEHLER" hinzugefügt.
Ebenfalls habe ich das Attribut "FEHLERCODE" definiert.
Dem "FEHLER" habe ich über [Nachrichtentext] eine Meldungsnummer zugewiesen und das Attribut FEHLERCODE verwendet.
Die Meldung heißt dann zum Beispiel:
Es ist ein Fehler aufgetreten. Fehlercode: "&".
Der Aufruf der Exception sieht etwas so aus:
Jetzt sind den Fehlercodes aber immer gleiche Bedeutungen zugeordnet:
1 = Fehler beim Löschen
2 = Fehler beim Lesen
3 = Fehler beim Speichern
4 = Fehler beim Prüfen
5 = Berechtigungsfehler
...
Ich möchte nun aber nicht jedes mal die entsprechende Bedeutung nachlesen (Also entweder VOR dem werfen der Exception oder NACH dem CATCH) um die Bedeutung in die Meldung zu schreiben.
Habe ich irgendwie die Möglichkeit, dass die Fehlerklasse diese Aufgabe selbst übernimmt um selbst gleich die richtige Fehlermeldung ausgeben zu können???
Das Ersetzen der Attribute in die Message-Variablen erfolgt in CL_MESSAGE_HELPER->SET_MSG_VARS_FOR_IF_t100_MSG.
Die müsste ich selbst aufrufen, nur leider kann man ja den CONSTRUCTOR der Exceptionklasse nicht ändern... ;(
Danke und Gruß
ich ärgere mich gerade mit EXCEPTION-Klassen herum...
Ich frage mich, ob es möglich ist, die übergebenen Werte bei Auslösen der Exception noch irgendwie auszuwerten?!
Beispiel:
Ich habe eine Ausnahmeklasse definiert und den TEXT "FEHLER" hinzugefügt.
Ebenfalls habe ich das Attribut "FEHLERCODE" definiert.
Dem "FEHLER" habe ich über [Nachrichtentext] eine Meldungsnummer zugewiesen und das Attribut FEHLERCODE verwendet.
Die Meldung heißt dann zum Beispiel:
Es ist ein Fehler aufgetreten. Fehlercode: "&".
Der Aufruf der Exception sieht etwas so aus:
Code: Alles auswählen.
RAISE EXCEPTION TYPE ZCX_ENNOS_FEHLERKLASSE
EXPORTING
textid = ZCX_ENNOS_FEHLERKLASSE=>FEHLER
fehlercode = 5.
Jetzt sind den Fehlercodes aber immer gleiche Bedeutungen zugeordnet:
1 = Fehler beim Löschen
2 = Fehler beim Lesen
3 = Fehler beim Speichern
4 = Fehler beim Prüfen
5 = Berechtigungsfehler
...
Ich möchte nun aber nicht jedes mal die entsprechende Bedeutung nachlesen (Also entweder VOR dem werfen der Exception oder NACH dem CATCH) um die Bedeutung in die Meldung zu schreiben.
Habe ich irgendwie die Möglichkeit, dass die Fehlerklasse diese Aufgabe selbst übernimmt um selbst gleich die richtige Fehlermeldung ausgeben zu können???
Das Ersetzen der Attribute in die Message-Variablen erfolgt in CL_MESSAGE_HELPER->SET_MSG_VARS_FOR_IF_t100_MSG.
Die müsste ich selbst aufrufen, nur leider kann man ja den CONSTRUCTOR der Exceptionklasse nicht ändern... ;(
Danke und Gruß
Zuletzt geändert von ewx am 13.08.2015 16:40, insgesamt 1-mal geändert.
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
)
»
Schließe mich der Frage an: Ich hätte das auch schon öfters benötigt!
Bislang hab ich keine bessere Lösung gefunden als eine "Factory"-Klasse für bestimmte Exceptions zu erstellen bzw. die Ermittlung der zusätzlichen Daten in eine eigene Methode auszulagern, diese VOR dem Aufruf der Exception aufzurufen und das Ergebnis dann beim RAISE mitzuübergeben.
Alternativ, da es bei dir ja um fixe(?) Texte geht, könntest du die Nachrichtenklassen weglassen und für jeden Returncode einen eigenen Fehlertext in der Exceptionklasse definieren.
lg ADT
Bislang hab ich keine bessere Lösung gefunden als eine "Factory"-Klasse für bestimmte Exceptions zu erstellen bzw. die Ermittlung der zusätzlichen Daten in eine eigene Methode auszulagern, diese VOR dem Aufruf der Exception aufzurufen und das Ergebnis dann beim RAISE mitzuübergeben.
Alternativ, da es bei dir ja um fixe(?) Texte geht, könntest du die Nachrichtenklassen weglassen und für jeden Returncode einen eigenen Fehlertext in der Exceptionklasse definieren.
lg ADT
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 ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Irgendwie verstehe ich euer Problem nicht - jeder unterschiedliche Fehler (= jede unterschiedliche Fehlerbehandlung) bedarf einer eigenen Fehlerklasse.
Was wollt ihr denn danach noch auswerten?
Was wollt ihr denn danach noch auswerten?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Enno möchte einen generischen Text verwenden und diesen hinten einfach entsprechend eines Returncodes verändern. (Klarer Fall von fauler Programmierer 
)
Ich möchte z.B. den Benutzernamen an die Exceptionklasse übergeben können und im Fehlertext soll dann aber der Name aus dem Benutzerstamm (uU mit Telefonnummer) aufscheinen.
Grob gesagt geht es darum den Text aus der Exception "sprechender" zu gestalten um ihn für eine Ausgabe verwenden zu können mit der auch der Anwender etwas anfangen kann.
lg ADT
)Ich möchte z.B. den Benutzernamen an die Exceptionklasse übergeben können und im Fehlertext soll dann aber der Name aus dem Benutzerstamm (uU mit Telefonnummer) aufscheinen.
Grob gesagt geht es darum den Text aus der Exception "sprechender" zu gestalten um ihn für eine Ausgabe verwenden zu können mit der auch der Anwender etwas anfangen kann.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
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 ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Was spricht dagegen, entsprechende Variablen in der Message zu verwenden?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Das mach ich ja jetzt bereits.
Ich und Enno sind halt nur faule Programmierer und suchen stets nach Möglichkeiten uns das Schreiben von "unnötigen" Code zu ersparen.
Im Falle von den Exceptionklassen muss man VORHER immer die gleiche Befüllung der Variablen durchführen und das nervt irgendwie.
(Nur weil man den Constructor einer Exception nicht manuell bearbeiten darf)
lg ADT
Ich und Enno sind halt nur faule Programmierer und suchen stets nach Möglichkeiten uns das Schreiben von "unnötigen" Code zu ersparen.
Im Falle von den Exceptionklassen muss man VORHER immer die gleiche Befüllung der Variablen durchführen und das nervt irgendwie.
(Nur weil man den Constructor einer Exception nicht manuell bearbeiten darf)
lg ADT
Zuletzt geändert von a-dead-trousers am 14.08.2015 09:29, insgesamt 1-mal geändert.
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
Wie oben beschrieben müsstest du das immer den Aufrufer erledigen lassen oder den "Abfänger" der Ausnahme bevor die Meldung ausgegeben wird.ralf.wenzel hat geschrieben:Was spricht dagegen, entsprechende Variablen in der Message zu verwenden?
Du brauchst also zwei Meldungsnummern (analog zu adt's Beispiel):
1. Objekt gesperrt von ENNO
2. Objekt gesperrt von Enno Wulff, telefonisch erreichbar unter 01234 5678-90.
Eventuell kann man was reißen, in dem man GET_TEXT redefiniert.
Nur leider wird die Methode nicht aufgerufen bei
Code: Alles auswählen.
MESSAGE gx_error TYPE 'E'.Ich würde den Begriff "effizient" vorziehen...a-dead-trousers hat geschrieben: Ich und Enno sind halt nur faule Programmierer [...]
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hmmm... Das könnte zumindest für meinen Fall genau die Lösung sein, die ich brauche...ewx hat geschrieben:Eventuell kann man was reißen, in dem man GET_TEXT redefiniert.
Nur leider wird die Methode nicht aufgerufen beiCode: Alles auswählen.
MESSAGE gx_error TYPE 'E'.
Das ich da nicht schon selber drauf gekommen bin:
Einfach vor dem Super-Aufruf von GET_TEXT bzw. GET_LONGTEXT die entsprechenden Variablen der Exception-Klasse "umschreiben".
Wie meinst du das mit MESSAGE? Da sind doch keine EXCEPTIONS im Spiel oder hab ich da was übersehen?
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
)
»
Oh...
ABAP-Hilfe hat geschrieben:MESSAGE - { oref TYPE mtype }
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 ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das mit der Effizienz ist so eine Sache. Es gibt Leute, die aus Effizienzgründen sy-marky als Universalflag verwenden.
Zum Problem kann ich leider nichts sagen, weil ich eigentlich seit geraumer Zeit die Messages erst im Aufrufer setze, weil ich die Message für GUI-abhängig halte. Sprich: Die Klasse mit der Business-Logik setzt eine Ausnahme und (zum Beispiel) der Report mit der GUI-Logik setzt anhand der Ausnahmeklasse die Message.
Zum Problem kann ich leider nichts sagen, weil ich eigentlich seit geraumer Zeit die Messages erst im Aufrufer setze, weil ich die Message für GUI-abhängig halte. Sprich: Die Klasse mit der Business-Logik setzt eine Ausnahme und (zum Beispiel) der Report mit der GUI-Logik setzt anhand der Ausnahmeklasse die Message.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hast die Doku schneller gefunden, als ich...
DAS ist faul!ralf.wenzel hat geschrieben:Das mit der Effizienz ist so eine Sache. Es gibt Leute, die aus Effizienzgründen sy-marky als Universalflag verwenden.
Jein. Einerseits hast du IMHO Recht, dass die Funktion, die die Exception wirft, keine aussagekräftige Meldung erzeugen muss. Es würde evtl. reichenralf.wenzel hat geschrieben: Zum Problem kann ich leider nichts sagen, weil ich eigentlich seit geraumer Zeit die Messages erst im Aufrufer setze, weil ich die Message für GUI-abhängig halte. Sprich: Die Klasse mit der Business-Logik setzt eine Ausnahme und (zum Beispiel) der Report mit der GUI-Logik setzt anhand der Ausnahmeklasse die Message.
Code: Alles auswählen.
RAISE EXCEPTION TYPE zcx_abc
exporting
textid = zcx_abc=>keine_berechtigung
user = 'XYZ'.Aber: Sie muss ja nicht anders sein. Und gerade, wenn Fehler protokolliert werden, ist es einfacher, die originäre Meldung zu verwenden ohne diese nochmal aufbereiten zu müssen. Und warum sollte das nicht die Exception-Class selbst übernehmen?
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das liegt im Auge des Betrachters.ewx hat geschrieben:DAS ist faul!ralf.wenzel hat geschrieben:Das mit der Effizienz ist so eine Sache. Es gibt Leute, die aus Effizienzgründen sy-marky als Universalflag verwenden.
Weil die Exception Class nicht GUI-abhängig sein sollte. Finde ich.ewx hat geschrieben:Der Aufrufer muss dann entscheiden, wie die Meldung aussieht; die kann ja je nach Kontext anders sein.
Aber: Sie muss ja nicht anders sein. Und gerade, wenn Fehler protokolliert werden, ist es einfacher, die originäre Meldung zu verwenden ohne diese nochmal aufbereiten zu müssen. Und warum sollte das nicht die Exception-Class selbst übernehmen?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
ewx hat geschrieben:Hast die Doku schneller gefunden, als ich...
Ich versteh das so: Wenn deine Exceptionklasse KEINE Nachrichtenklasse verwendet (weil bei IF_T100_MESSAGE gibt es ja den T100KEY der stattdessen herangezogen wird) würde die Aufbereitung sehrwohl über die GET_TEXT und GET_LONGTEXT laufen.ABAP-Hilfe hat geschrieben:Aus Kompatibilitätsgründen kann diese Variante auch noch für Klassen verwendet werden, die nur das Interface IF_MESSAGE implementieren. In diesem Fall werden im referenzierten Objekt automatisch die Interfacemethoden GET_TEXT und GET_LONGTEXT aufgerufen und deren Rückgabewert als Kurztext bzw. Langtext der Nachricht verwendet. Die Systemfelder sy-msgid und sy-msgno werden in diesem Fall nicht spezifisch gefüllt. Die Wurzelklasse aller Ausnahmeklassen, CX_ROOT, implementiert das Interface IF_MESSAGE. In Ausnahmeklassen, die nicht das Interface IF_T100_MESSAGE implementieren, besorgen die Interfacemethoden GET_TEXT und GET_LONGTEXT die im OTR (Online Text Repository) abgelegten Ausnahmetexte von Ausnahmeobjekten, die dann mit dieser Variante der MESSAGE-Anweisung als Nachricht ausgegeben werden können.
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
Vergleichbare Themen
2
Antw.
Antw.
1829
Views
Views
2
Antw.
Antw.
1187
Views
Views
3
Antw.
Antw.
2905
Views
Views
ALV -> Exceptions / Lights -> Spaltenname
von m4rkusr » 26.09.2007 09:38 • Verfasst in ABAP Objects®
von m4rkusr » 26.09.2007 09:38 • Verfasst in ABAP Objects®
9
Antw.
Antw.
3064
Views
Views
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.