Exceptions
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Es ist eigentlich auch nicht logisch, dass man den Constructor in einer kundeneigenen Klasse nicht ändern kann. Insofern ist die Einschränkung in der SE24 wohl eher als Fehler zu bezeichnen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Danke für deinen Würg-Around! 
Wahrscheinlich wird man damit leben müssen, dass einige Dinge nur noch in Eclipse möglich sein werden.
Wahrscheinlich wird man damit leben müssen, dass einige Dinge nur noch in Eclipse möglich sein werden.
Das dürfte auch immer noch so sein, denn im Cosntructor werden alle definierten Attribute hineingeneriert. Spätestens, wenn ich ein neues Attribut anlegen, wird die Änderung im Constructor also futsch sein.black_adept hat geschrieben: Ich glaube zwar, dass es in älteren Releaseständen beim Aktivieren oder Neugenrieren der Klasse dazu kam, dass der Constructor wieder auf das Original zurück gesetzt wurde - aber das schein bei neueren Releases inzw. nicht mehr der Fall zu sein.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das werden immer mehr. Mit jedem Releasestand.ewx hat geschrieben:Danke für deinen Würg-Around!
Wahrscheinlich wird man damit leben müssen, dass einige Dinge nur noch in Eclipse möglich sein werden.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hmm - ist da nicht Ennos Ansatz genau der Richtige dann?ralf.wenzel hat geschrieben:[...]
Denn WENN die Messages in einem SAPUI5 nicht einfach so verwertbar sind, werden wir eine Lösung brauchen, wie aus einer Exception Class eine gescheite Frontend-Meldung kriegen, wenn eben NICHT mehr alles in einer integrierten Applikation passiert, sondern das Frontend ein x-beliebiger Browser oder ein App ist, das HTML5 macht.
[...]
Exceptionclasses mit Messagebezug ( ich bevorzuge Exceptionclasses, denen ich eine SYST-Kopie übergebe, und wo ich vor dem Raise ein Message ... into textfeld mache ) sorgen doch zunächst einmal dafür, dass zunächst unabhängig von der Darstellung etwas mitgeteilt wird.
Und jetzt ist ja der Frontend - wie auch immer der heute oder in Zukunft aussehen mag - zuständig für die Ausgabe der Informationen, die der Exceptionauslöser mitgeben wollte.
Und ob das für eine SAPGUI nun über den MESSAGE-Befehl geht oder über eine JavaScript-Anweisung window.alert ist eigentlich egal.
Letztlich brauchst du ein Interface, welches der Exception die Information wieder entlockt. Und da finde ich Ennos Ansatz absolut korrekt, wenn er sagt, dass die Exceptionklasse selber für die Bereitstellung eines aussagekräftigen oder angereicherten Fehlertextes sorgen sollte, denn bis hier hin ist das immer noch ein GUI-unabhängiger Inhalt den die Gui nun dem User präsentieren muss.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Du hättest recht, wenn nicht der Aufrufer darüber entscheiden würde, was gemacht wird. Nicht jeder Fehler erzeugt eine Fehlermeldung, so wie auch niemand auf die Idee käme, eine sy-subrc-Abfrage systemweit mit einer Meldungsausgabe hart zu verbinden.
Es gibt durchaus Situationen, in denen aus dem Aufrufer A und aus dem Aufrufer B dieselbe Methode gerufen wird. Im Kontext der Methode ist das Nicht-Vorhandensein eines Datensatzes immer ein Fehler, weil die Methode nicht weiterarbeiten kann. Also meldet die Methode den für sie fehlerhaften Zustand an den Aufrufer A oder B. Aufrufer A kann ohne Ergebnis der Methode nicht weiterarbeiten und wirft deshalb eine Message, Aufrufer B nutzt die Ausnahme als Kennung für eine alternative Logik, die im Catch durchlaufen wird.
Ich benutze Ausnahmeklassen daher nur als "Flag", das anzeigt, das eine ungeplante Situation aufgetreten ist und welche. Ob dann etwas passiert und was, entscheide ich immer im Kontext des Aufrufers. Ich ärgere mich die Krätze über jede hart codierte Message in einem Funktionsbaustein, weil eine Ausnahmesituation nicht zwingend ein "messagewürdiger" Fehler ist.
Ich kenne das Problem doch selbst: Man kapselt ein Coding und sieht dieses Coding in einem Kontext, in dem man es benutzt, und sei es nur die SAPGUI. Ein anderer Aufrufer ärgert sich später über zu statisches Verhalten, weil er dieses Coding aus einer Java-Anwendung heraus aufruft und mit "message" nichts anfangen kann.
Es gibt durchaus Situationen, in denen aus dem Aufrufer A und aus dem Aufrufer B dieselbe Methode gerufen wird. Im Kontext der Methode ist das Nicht-Vorhandensein eines Datensatzes immer ein Fehler, weil die Methode nicht weiterarbeiten kann. Also meldet die Methode den für sie fehlerhaften Zustand an den Aufrufer A oder B. Aufrufer A kann ohne Ergebnis der Methode nicht weiterarbeiten und wirft deshalb eine Message, Aufrufer B nutzt die Ausnahme als Kennung für eine alternative Logik, die im Catch durchlaufen wird.
Ich benutze Ausnahmeklassen daher nur als "Flag", das anzeigt, das eine ungeplante Situation aufgetreten ist und welche. Ob dann etwas passiert und was, entscheide ich immer im Kontext des Aufrufers. Ich ärgere mich die Krätze über jede hart codierte Message in einem Funktionsbaustein, weil eine Ausnahmesituation nicht zwingend ein "messagewürdiger" Fehler ist.
Ich kenne das Problem doch selbst: Man kapselt ein Coding und sieht dieses Coding in einem Kontext, in dem man es benutzt, und sei es nur die SAPGUI. Ein anderer Aufrufer ärgert sich später über zu statisches Verhalten, weil er dieses Coding aus einer Java-Anwendung heraus aufruft und mit "message" nichts anfangen kann.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Es geht ja gar nicht darum eine Message auszugeben, sondern darum, dass die Exception zu einem kryptischen, nicht ohne weiteres verständlichen code selbstständig einen beschreibenden Text liefert.
Was der Aufrufer damit dann macht, kann er ja immer noch selbst entscheiden. Nur weil eine Message-Information mitgegeben wird, heisst es ja nicht, dass diese auch ausgegeben wird (Im Sinne von MESSAGE...).
Wenn der Aufrufer diese Info aber ausgeben möchte, dann soll das ohne weiteres nachlesen von Informationen möglich sein.
Also: anstelle von
Konditionsart ABCD Nicht im Kalkulationsschema vorhanden
Besser
Konditionsart ABCD "Frachtkosten XY" nicht im Kalkulationsschema vorhanden.
Was der Aufrufer damit dann macht, kann er ja immer noch selbst entscheiden. Nur weil eine Message-Information mitgegeben wird, heisst es ja nicht, dass diese auch ausgegeben wird (Im Sinne von MESSAGE...).
Wenn der Aufrufer diese Info aber ausgeben möchte, dann soll das ohne weiteres nachlesen von Informationen möglich sein.
Also: anstelle von
Konditionsart ABCD Nicht im Kalkulationsschema vorhanden
Besser
Konditionsart ABCD "Frachtkosten XY" nicht im Kalkulationsschema vorhanden.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das ist richtig.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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.