Exceptions
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Moment...
Demnach sollte es auch für Nachrichtenklassen mit der Redefinition funktionieren.ABAP-Hilfe hat geschrieben:Diese Variante ist hauptsächlich zur Verwendung mit Ausnahmeobjekten vorgesehen. Wenn eine globale Ausnahmeklasse das Interface IF_T100_MESSAGE implementiert, werden die Komponenten der Struktur T100KEY beim Auslösen einer entsprechenden Ausnahme in der Interfacemethode GET_TEXT, die in der Oberklasse CX_ROOT implementiert ist, gemäß der Definition des zugehörigen Ausnahmetexts gefüllt. Bei lokalen Ausnahmeklassen muss man die Komponenten selbst füllen. Hierfür sollte aber nicht die Interfacemethode GET_TEXT redefiniert, sondern der Instanzkonstruktor verwendet werden.
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Da könntest du Recht haben. Was mich daran stört ist das vorangehende "aus Kompatibilitätsgründen".a-dead-trousers hat geschrieben: 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.
Müsste MAN mal ausprobieren... :]
Wie gesagt: Jein.ralf.wenzel hat geschrieben:Weil die Exception Class nicht GUI-abhängig sein sollte. Finde ich.
Das würde bedeuten, dass deine GUI/ Anwendungsprogramm alle Fehler können müsste, die in allen aufrufenden Funktionen auftreten können. Ich würde mal sagen, das ist recht nah an "unmöglich".
Dementsprechend spricht also m. E. nichts dagegen, "Systemmeldungen" so sprechend wie möglich zu machen.
Ansonsten muss ich bei allen Fehlercodes und technischen Abkürzungen wissen, in welcher Doku die Erklärung dazu steht.
Was Bedeutet:
- Keine Berechtigung für Aktivität "03"?
- Fehler "404" bei Aufruf von "Preisliste ermitteln"
- Keine Währungseinheit für Vorgangsart "KP" vorhanden
- ...
Das sind Meldungen, die sind unabhängig vom Kontext/ GUI. also darf sie auch möglichst sprechend sein. Und zwar ohne, dass sich jemand anderes ausser der Ausnahmeklasse darum kümmern muss.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Wie löst du denn die Probleme, wenn es die SAPGUI nicht mehr gibt? SAPUI5 kommt in Riesenschritten (ich weiß gar nicht, wie sich Messages da verhalten)....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Genau da hilft "mein" Verfahren ja weiter. Bei kryptischen Fehlermeldungen müsstest du sie im UI allesamt nachprogrammieren.
Davon abgesehen, dass das gar nicht zur Debatte steht. Das ginge ja nur, wenn die Applikation bereits mit MVC programmiert wurde.
Aber das Thema sollten wir nicht hier weiter verwursten.
Mir geht es in erster Linie darum, wie ich am besten und einfachsten und sinnvollsten mit den Ausnahmeklassen zurecht komme.
Davon abgesehen, dass das gar nicht zur Debatte steht. Das ginge ja nur, wenn die Applikation bereits mit MVC programmiert wurde.
Aber das Thema sollten wir nicht hier weiter verwursten.
Mir geht es in erster Linie darum, wie ich am besten und einfachsten und sinnvollsten mit den Ausnahmeklassen zurecht komme.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Genau. Bloß nicht an die Zukunft denken, die ist ja noch weit weg. 
Und in drei Jahren verdienen wir nochmal an dem Programm, weil wir es neu schreiben.
Sorry, auf "das mache ich jetzt pragmatisch für heute, über morgen denke ich erst nach, wenn es das nächste Mal hell wird" reagiere ich in letzter Zeit ziemlich gereizt. Ich kämpfe gerade gegen Windmühlen.
Und in drei Jahren verdienen wir nochmal an dem Programm, weil wir es neu schreiben.Sorry, auf "das mache ich jetzt pragmatisch für heute, über morgen denke ich erst nach, wenn es das nächste Mal hell wird" reagiere ich in letzter Zeit ziemlich gereizt. Ich kämpfe gerade gegen Windmühlen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ralf, du kannst einem echt die Worte im Mund umdrehen... 
du schaffst es regelmäßig, aus einer speziellen Fragestellung eine Grundsatzdiskussion zu machen.
/edit: ...Und den Fragesteller als ignoranten, inkompetenten Deppen dastehen zu lassen.
Sorry, darauf reagiere ICH allergisch.
du schaffst es regelmäßig, aus einer speziellen Fragestellung eine Grundsatzdiskussion zu machen.
/edit: ...Und den Fragesteller als ignoranten, inkompetenten Deppen dastehen zu lassen.
Sorry, darauf reagiere ICH allergisch.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Enno, ich erwähne dich und deinen Tricktresor nicht in meinen iX-Artikeln (eiweh, da liegt noch ne Leiche auf meinem Schreibtisch, auf die die warten), weil ich dich für einen ignoranten Deppen halte.ewx hat geschrieben:Ralf, du kannst einem echt die Worte im Mund umdrehen...
du schaffst es regelmäßig, aus einer speziellen Fragestellung eine Grundsatzdiskussion zu machen.
/edit: ...Und den Fragesteller als ignoranten, inkompetenten Deppen dastehen zu lassen.
Sorry, darauf reagiere ICH allergisch.
Und nein, ich drehe dir nicht das Wort im Mund um, ich denke nur, dass wir (gerade vor dem Hintergrund, dass hier auch andere mitlesen und wir nicht nur unsere akuten Probleme lösen - das ist ja hier auch ein Nachschlagewerk) nicht einfach die zwingende Entwicklung, die unmittelbar vor uns steht, ausblenden sollten.
Gerade sitze ich bei einem Kunden, der die Migration zu S/4HANA beschlossen hat und versuche solche Dinge so zu organisieren, dass wir die Geschäftslogik eben nicht neu anfassen müssen in zwei Jahren. Dazu gehört, dass man STRENG die UI kapselt, damit man sie austauschen kann.
Auch wir (rechts oben steht was von "Top Expert", das steht bei dir ja auch, auch wenn ich solche Bezeichnungen immer schwierig finde) sollten langsam anfangen, uns darauf einzustellen und Lösungen zu entwickeln, die auch in drei Jahren noch funktionieren. Sonst sind wir irgendwann die Dinosaurier....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4282 / 214 /
1141
)
»
Da schließe ich mich jetzt enno an:
Einmal sagst du, dass sich in Zukunft alles so sehr ändert und dann verschließt du die Augen vor dem Vorteil, den Exceptions in zukünftigen Lösung hier bieten können. Nämlich, dass alles releavante schon da ist und nicht umständlich von einer "alten" GUI Lösung auf das Web umgeschrieben werden müsste.
Und selbst wenn du jetzt bereits alles mit deiner eigenen supertollen Lösung im WebUI machst (soll jetzt nicht heißen, dass die schlecht ist), wer garantiert dir denn, dass irgendwann mal das WebUI nicht von was ganz anderem abgelöst wird. Dann ist deine Lösung vielleicht plötzlich auch nicht mehr so toll, weil dann erst wieder zusätzlicher Portierungsaufwand für die Fehlerausgabe entsteht. Hingegen sind Exceptions inzwischen ein fundamentaler Bestandteil einer jeden Programmiersprache und werden gerade weil sie sehr technisch sind wohl nicht so schnell von der "Optimierungswelle" überrollt.
Da ist ja von allen Seiten (C, JAVA uvm.) sehr viel Know-How reingeflossen um von Return-Codes auf aussagekräftige Fehlerklassen zu kommen. Hingegen stecken UI Lösungen meines Erachtens nach wie vor noch in den Kinderschuhen, da man nie sagen kann ob das was für A wunderbar funktioniert nicht für B der größte Schwachsinn ist den es gibt.
ralf.wenzel hat geschrieben:Wie löst du denn die Probleme, wenn es die SAPGUI nicht mehr gibt? SAPUI5 kommt in Riesenschritten
ewx hat geschrieben:Genau da hilft "mein" Verfahren ja weiter. Bei kryptischen Fehlermeldungen müsstest du sie im UI allesamt nachprogrammieren.
Kannst du BITTE einmal erklären wie du zwei so derart diametral unterschiedliche Argumentationen führen kannst?ralf.wenzel hat geschrieben:Genau. Bloß nicht an die Zukunft denken, die ist ja noch weit weg.
Einmal sagst du, dass sich in Zukunft alles so sehr ändert und dann verschließt du die Augen vor dem Vorteil, den Exceptions in zukünftigen Lösung hier bieten können. Nämlich, dass alles releavante schon da ist und nicht umständlich von einer "alten" GUI Lösung auf das Web umgeschrieben werden müsste.
Und selbst wenn du jetzt bereits alles mit deiner eigenen supertollen Lösung im WebUI machst (soll jetzt nicht heißen, dass die schlecht ist), wer garantiert dir denn, dass irgendwann mal das WebUI nicht von was ganz anderem abgelöst wird. Dann ist deine Lösung vielleicht plötzlich auch nicht mehr so toll, weil dann erst wieder zusätzlicher Portierungsaufwand für die Fehlerausgabe entsteht. Hingegen sind Exceptions inzwischen ein fundamentaler Bestandteil einer jeden Programmiersprache und werden gerade weil sie sehr technisch sind wohl nicht so schnell von der "Optimierungswelle" überrollt.
Da ist ja von allen Seiten (C, JAVA uvm.) sehr viel Know-How reingeflossen um von Return-Codes auf aussagekräftige Fehlerklassen zu kommen. Hingegen stecken UI Lösungen meines Erachtens nach wie vor noch in den Kinderschuhen, da man nie sagen kann ob das was für A wunderbar funktioniert nicht für B der größte Schwachsinn ist den es gibt.
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 / 3776 / 176 /
262
)
»
Also, meinem Kenntnisstand (und ich habe klar geschrieben, dass ich noch nicht weiß, wie sich SAPGUI-Messages in SAPUI5 verhalten) sind Messages SAPGUI spezifisch. Darum habe ich die FRAGE gestellt, wie er denn das Problem unter SAPUI5 zu lösen gedenkt. Diese Frage ist erkennbar am Fragezeichen. Eine Frage ist dadurch gekennzeichnet, dass in aller Regel die Antwort noch nicht verfügbar ist. Ich erkläre das nur mal, für die, denen das kurzzeitig entgangen ist.
Weißt DU, wie sich eine I- oder eine E-Message auf einer Apple Watch verhalten? Ich weiß das nicht, ich weiß auch nicht, ob die Frage irgendwann relevant werden wird. Trotzdem sage ich, dass wir langsam anfangen sollten, uns mit diesen Fragen zu beschäftigen. Wenn wir das nicht heute tun, machen wir es morgen und dann schießen wir wieder aus der Hüfte. Damit "Bei kryptischen Fehlermeldungen....nachprogrammieren" eben nicht in das ausartet, nach dem es derzeit aussieht, sollten wir schon jetzt anfangen, entsprechende Konzepte zu entwickeln. Ich bin mir sicher, dass man das von uns erwartet und dass uns der Kunde mit dem nackten Arsch ins Gesicht springt, wenn wir in drei, vier Jahren komplette Anwendungen wegwerfen, weil die UI sich ändert.
Insofern ist die Argumentation nicht diametral unterschiedlich, sondern das Zweite eine Folgerung des Ersten. 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.
Ich habe keine supertolle WebUI-Lösung. Ich versuche nur, über den aktuellen Projektauftrag hinaus zu denken. Darum habe ich eine Fra-ha-ge gestellt. Es kann sein, dass IRGENDWANN etwas vollkommen anderes kommt, das jetzt weder definiert ist noch irgendwie einschätzbar. SAPUI5 dagegen ist beschlossen und in ersten Lösungen schon produktiv.
Es gibt einen deutlichen Unterschied zwischen "wir machen das in drei Jahren genau SO" und "vielleicht machen wir es irgendwann viel später doch noch anders, wissen aber noch nicht, wie". Ersteres kann man berücksichtigen, Letzteres nicht.
Und gerade DANN, WENN die UI-Lösungen noch in den Kinderschuhen stecken, ist es erstrecht ein Grund, sie zu kapseln. Und solange mir keiner etwas anderes nachvollziehbar erklärt, ist eine MESSAGE-Anweisung eine SAPGUI-spezifische Anweisung auf einem SAPGUI-Frontend, deren Verhalten ich auf einem Android-Tablet, einer Apple Watch oder einem Windows Phone nicht abschätzen kann.
Ja, mein Ton ist nicht immer so dolle, das ist wohl auch der Grund, warum ich nicht im diplomatischen Dienst der Bundesregierung arbeite, sondern mir einen Beruf ausgesucht hat, in dem Streit und Diskussion an der Tagesordnung sind und jeden der Beteiligten weiterbringen. In der Sache weiche ich keinen Deut vom Geschriebenen ab.
Weißt DU, wie sich eine I- oder eine E-Message auf einer Apple Watch verhalten? Ich weiß das nicht, ich weiß auch nicht, ob die Frage irgendwann relevant werden wird. Trotzdem sage ich, dass wir langsam anfangen sollten, uns mit diesen Fragen zu beschäftigen. Wenn wir das nicht heute tun, machen wir es morgen und dann schießen wir wieder aus der Hüfte. Damit "Bei kryptischen Fehlermeldungen....nachprogrammieren" eben nicht in das ausartet, nach dem es derzeit aussieht, sollten wir schon jetzt anfangen, entsprechende Konzepte zu entwickeln. Ich bin mir sicher, dass man das von uns erwartet und dass uns der Kunde mit dem nackten Arsch ins Gesicht springt, wenn wir in drei, vier Jahren komplette Anwendungen wegwerfen, weil die UI sich ändert.
Insofern ist die Argumentation nicht diametral unterschiedlich, sondern das Zweite eine Folgerung des Ersten. 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.
Ich habe keine supertolle WebUI-Lösung. Ich versuche nur, über den aktuellen Projektauftrag hinaus zu denken. Darum habe ich eine Fra-ha-ge gestellt. Es kann sein, dass IRGENDWANN etwas vollkommen anderes kommt, das jetzt weder definiert ist noch irgendwie einschätzbar. SAPUI5 dagegen ist beschlossen und in ersten Lösungen schon produktiv.
Es gibt einen deutlichen Unterschied zwischen "wir machen das in drei Jahren genau SO" und "vielleicht machen wir es irgendwann viel später doch noch anders, wissen aber noch nicht, wie". Ersteres kann man berücksichtigen, Letzteres nicht.
Und gerade DANN, WENN die UI-Lösungen noch in den Kinderschuhen stecken, ist es erstrecht ein Grund, sie zu kapseln. Und solange mir keiner etwas anderes nachvollziehbar erklärt, ist eine MESSAGE-Anweisung eine SAPGUI-spezifische Anweisung auf einem SAPGUI-Frontend, deren Verhalten ich auf einem Android-Tablet, einer Apple Watch oder einem Windows Phone nicht abschätzen kann.
Ja, mein Ton ist nicht immer so dolle, das ist wohl auch der Grund, warum ich nicht im diplomatischen Dienst der Bundesregierung arbeite, sondern mir einen Beruf ausgesucht hat, in dem Streit und Diskussion an der Tagesordnung sind und jeden der Beteiligten weiterbringen. In der Sache weiche ich keinen Deut vom Geschriebenen ab.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo zusammen.
Mal die Grundsatzdiskussionen fröhlich ignoriert (und auch die über Notationen und Präfixe): Nachrichten zu Exceptions per Message auszuwerfen mag ja im jeweiligen Umfeld gehen. Andere wollen sie lieber ins Applikationslog ausgeben, insofern bin ich immer vorsichtig mit dem Message-Befehl.
Wenn es aber um inhaltliche Aufbereitung geht (BP-Nr. beim Raise mitgeben, in der Meldung aber den Namen ausgeben), die so immer erfolgen soll, kann das doch in einer eigenen Methode geschehen, die man der Exception-Klasse hinzufügt.
Man könnte also innerhalb einer Methode PREPARE_MSG( ) die Nachricht aufbereiten und dann
- per MESSAGE ... INTO LD_TEXT in die Systemfelder schreiben.
- per MESSAGE ausgeben (definitiv unschön, der Aufrufer soll selbst entscheiden, was passiert)
- in anderen Variablen die Infos zurückreichen
- ...
(der Phantasie sind da doch keine Grenzen gesetzt).
Und der Aufrufer müsste ggfs. nur einen Methodenaufruf zusätzlich einbauen
CATCH ZCX_ABC INTO LCX_ABC.
MESSAGE LCX_ABC.
wird dann halt zu
CATCH ZCX_ABC INTO LCX_ABC.
LCX->PREPARE_MESSAGE( ).
MESSAGE SY-MSG ...
Dann hätte man die Aufbereitung vom Kontext her an die Exceptionklasse gehängt und der Aufwand bei der Ausgabe ist überschaubar.
Mal die Grundsatzdiskussionen fröhlich ignoriert (und auch die über Notationen und Präfixe): Nachrichten zu Exceptions per Message auszuwerfen mag ja im jeweiligen Umfeld gehen. Andere wollen sie lieber ins Applikationslog ausgeben, insofern bin ich immer vorsichtig mit dem Message-Befehl.
Wenn es aber um inhaltliche Aufbereitung geht (BP-Nr. beim Raise mitgeben, in der Meldung aber den Namen ausgeben), die so immer erfolgen soll, kann das doch in einer eigenen Methode geschehen, die man der Exception-Klasse hinzufügt.
Man könnte also innerhalb einer Methode PREPARE_MSG( ) die Nachricht aufbereiten und dann
- per MESSAGE ... INTO LD_TEXT in die Systemfelder schreiben.
- per MESSAGE ausgeben (definitiv unschön, der Aufrufer soll selbst entscheiden, was passiert)
- in anderen Variablen die Infos zurückreichen
- ...
(der Phantasie sind da doch keine Grenzen gesetzt).
Und der Aufrufer müsste ggfs. nur einen Methodenaufruf zusätzlich einbauen
CATCH ZCX_ABC INTO LCX_ABC.
MESSAGE LCX_ABC.
wird dann halt zu
CATCH ZCX_ABC INTO LCX_ABC.
LCX->PREPARE_MESSAGE( ).
MESSAGE SY-MSG ...
Dann hätte man die Aufbereitung vom Kontext her an die Exceptionklasse gehängt und der Aufwand bei der Ausgabe ist überschaubar.
Danke GastX für die Rückkehr zum Thema!
Dass ich mir Methoden ausdenken kann, die Meldung vorher aufzubereiten, ist klar.
Mir ging es jedoch darum, dass eigentlich die Ausnahmeklasse selbst der ideale Ort dafür ist.
Helper-Funktionen sind toll, müssen dann aber auch konsequent von allen Programmierern angewendet werden...
Deswegen die Überlegung, ob es nicht eine Möglichkeit gibt, es die Klasse tun zu lassen, die eh in jedem Fall verwendet werden muss.
Dass ich mir Methoden ausdenken kann, die Meldung vorher aufzubereiten, ist klar.
Mir ging es jedoch darum, dass eigentlich die Ausnahmeklasse selbst der ideale Ort dafür ist.
Helper-Funktionen sind toll, müssen dann aber auch konsequent von allen Programmierern angewendet werden...
Deswegen die Überlegung, ob es nicht eine Möglichkeit gibt, es die Klasse tun zu lassen, die eh in jedem Fall verwendet werden muss.
Das weiß ich, Ralf! Und trotzdem kommt es so bei mir an.ralf.wenzel hat geschrieben: Enno, ich erwähne dich und deinen Tricktresor nicht in meinen iX-Artikeln (eiweh, da liegt noch ne Leiche auf meinem Schreibtisch, auf die die warten), weil ich dich für einen ignoranten Deppen halte.
Das hat auch wenig mit "nicht vorhandener Diplomatie" zu tun.
Man muss sich nicht immer höflich, vorsichtig und gewählt ausdrücken.
Man muss aber auch nicht das genaue Gegenteil tun.
Aber auch das brauchen wir glaube ich nicht hier breit treten.
Richtig.Helper-Funktionen sind toll, müssen dann aber auch konsequent von allen Programmierern angewendet werden...
Da mir keine Möglichkeit bekannt ist, wie man das "vollautomatisch" hinbekommt, kam mir der Gedanke, die Helperfunktion zumindest als Methode der Fehlerklasse zu implementieren. Dann muss sie zwar jeder Aufrufer auch nutzen, findet sie aber direkt an der Fehlerklasse und nicht in ganz anderen Bausteinen / Klassen. Falls mir doch noch was besseres einfällt...
Beitrag
von black_adept (Top Expert / 3944 / 105 /
886
)
»
@Enno und A-D-T:
Dies ist "nur" eine Einschränkung in der SE24, die das verhindert. Wenn ich in einem "normalen" Report eine eigene Ausnahmeklasse definiere ist es völlig normal, dass ich dort auch den Constructor ändern kann und das bezeiten auch tue.
Somit stellt sich eigentlich nur die Frage - wie kann man die SE24 austricksen, damit man eben auch den Constructor bearbeiten kann.
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.
Das stimmt nur bedingt :oP...nur leider kann man ja den CONSTRUCTOR der Exceptionklasse nicht ändern... ;(
Dies ist "nur" eine Einschränkung in der SE24, die das verhindert. Wenn ich in einem "normalen" Report eine eigene Ausnahmeklasse definiere ist es völlig normal, dass ich dort auch den Constructor ändern kann und das bezeiten auch tue.
Somit stellt sich eigentlich nur die Frage - wie kann man die SE24 austricksen, damit man eben auch den Constructor bearbeiten kann.
- Die sauberste Lösung die ich bisher gefunden habe: Statt mit der SE24 lege ich die Klasse (inkl. dem Bezug zu CX_STATIC_CHECK) mit Eclipse an. Dort kann man das problemlos so einstellen wie man mag ( bitte runterscrollen im Screenshot für die Codeänderung ) Vorteil bei dieser Version: Die Klasse wird sogar als Exceptionklasse klassifiziert
- Wenn man kein Eclipse zur Verfügung hat muss man sich eines Tricks behelfen. Man schreibe zunächst einen Report, welcher eine modifizierte Klassendefinition enthält.Aus der in diesem Report erstellten Ausnahmeklasse erstellt man nun die Klasse über die SE24 und das Importwerkzeug ( welches nicht sonderlich intuitiv ist, aber den Job macht ) Auch hier erhält man nun eine Klasse, die von CX_STATIC_CHECK erbt, welche man als Exceptionklasse verwenden kann - aber diese ist nicht als Exceptionklasse sondern nur als "allgemeine" Klasse definiert funktioniert aber trotzdem. ( kein Bild mehr - ich darf nur 3 Bilder hochladen)
Code: Alles auswählen.
REPORT. CLASS zcx_my_check DEFINITION INHERITING FROM cx_static_check. PUBLIC SECTION. METHODS constructor. ENDCLASS. CLASS zcx_my_check IMPLEMENTATION. METHOD constructor. super->constructor( textid = textid previous = previous ). BREAK-POINT. ENDMETHOD. ENDCLASS. END-OF-SELECTION. RAISE EXCEPTION TYPE zcx_my_check.
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.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Vergleichbare Themen
2
Antw.
Antw.
1608
Views
Views
2
Antw.
Antw.
1021
Views
Views
3
Antw.
Antw.
2756
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®
6
Antw.
Antw.
4224
Views
Views
RFC - Exceptions - kurze Frage
von Blueshape » 07.09.2004 11:17 • Verfasst in Exchange Infrastructure
von Blueshape » 07.09.2004 11:17 • Verfasst in Exchange Infrastructure
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.