Auskommentierten Code debuggen?
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Beitrag
von Patrick1982 (ForumUser / 33 / 4 /
0
)
»
Moin,
ist es irgendwie möglich, im Debugger (im Testsystem) einen auskommentierten Methodenaufruf auszuführen? Also wenn ich mit dem Debugger in der letzten ausführbaren Zeile darüber stehe?
Oder muss ich den Aufruf erst wieder einkommentieren und ins Testsystem transportieren? Den Transportaufwand würd ich mir gern sparen, weil das dann immer so ein Hickhack mit dem Fachbereich ist, der den freigeben muss..
Vielen Dank!
Patrick
ist es irgendwie möglich, im Debugger (im Testsystem) einen auskommentierten Methodenaufruf auszuführen? Also wenn ich mit dem Debugger in der letzten ausführbaren Zeile darüber stehe?
Oder muss ich den Aufruf erst wieder einkommentieren und ins Testsystem transportieren? Den Transportaufwand würd ich mir gern sparen, weil das dann immer so ein Hickhack mit dem Fachbereich ist, der den freigeben muss..
Vielen Dank!
Patrick
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 / 4397 / 223 /
1182
)
»
Du musst den Code leider wieder "ausführbar" machen.
Sag dem Fachbereich halt einfach nicht das du da was geändert hast 🤬
Sag dem Fachbereich halt einfach nicht das du da was geändert hast 🤬
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag (Insgesamt 2):
deejey • msfox
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
Ich baue in solchen Fällen eine Weiche ein, weiß keiner: Verfahren alt oder neu, dann im Debugger bei Bedarf Variable ändern so dass man die Ergebnisse vergleochen kann. Habe aber auch das eine oder andere mal vergessen es wieder auszubauen, auch Userabfrage auf meinen Namen sind schon produktiv gegangen
Darum mache ich so etwas prinzipiell NIE!
Habe diese Woche wieder gesehen wie jemand ein BREAK auf seinen Namen im Produkt hinterlassen hat. Vor Jahren im Projekt erlebt. Ich finde bei uns im Smartform immer User, die es schon seit 10 Jahren nicht mehr gibt und das Smartform ist deutschlandweit im Einsatz.
Sowas macht nur graue Haare...
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Pack den auskommentierten Code in einen "IF 1 = 0. call method ... ENDIF"-Block.
Der wird im Normalfall nie durchlaufen aber wenn du debuggen willst kannst du zur Not über das IF hinwegspringen.
Der wird im Normalfall nie durchlaufen aber wenn du debuggen willst kannst du zur Not über das IF hinwegspringen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
msfox
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Wo ist denn das Problem dabei? Ich habe schon im SAP-Originalcode personalisierte Breakpoints irgendwelcher SAP-Entwickler entdeckt. Dafür nimmt man die ja anstelle der generischen BREAK-POINT-Anweisung, die bei jedem Nutzer stehen bleiben würde. Ein Breakpoint, der nicht wirkt, richtet keinen Schaden an. Ich weiß nicht, wo Du an der Stelle graue Haare herbekommst.msfox hat geschrieben: ↑12.11.2020 13:32Darum mache ich so etwas prinzipiell NIE!
Habe diese Woche wieder gesehen wie jemand ein BREAK auf seinen Namen im Produkt hinterlassen hat. Vor Jahren im Projekt erlebt. Ich finde bei uns im Smartform immer User, die es schon seit 10 Jahren nicht mehr gibt und das Smartform ist deutschlandweit im Einsatz.
Sowas macht nur graue Haare...
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Besser wäre es die sogennanten Checkpointgruppen zu verwenden. Dann kann jeder Entwickler die Break-Points nutzen ohne "toten" (wenn der Entwickler nicht mehr in der Firma ist) Code zu hinterlassen. Zudem bleibt man dann als Entwickler auch nicht andauernd in der Applikation stehen wenn der eigene Break Point erreicht wird, man aber gar nichts debuggen möchte.DeathAndPain hat geschrieben: ↑17.11.2020 13:00Wo ist denn das Problem dabei? Ich habe schon im SAP-Originalcode personalisierte Breakpoints irgendwelcher SAP-Entwickler entdeckt. Dafür nimmt man die ja anstelle der generischen BREAK-POINT-Anweisung, die bei jedem Nutzer stehen bleiben würde. Ein Breakpoint, der nicht wirkt, richtet keinen Schaden an. Ich weiß nicht, wo Du an der Stelle graue Haare herbekommst.
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
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
816
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 12 Stunden von ralf.wenzel 104 / 10107
vor 12 Stunden von ralf.wenzel 104 / 10107
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 12 Stunden von ralf.wenzel 104 / 10107
vor 12 Stunden von ralf.wenzel 104 / 10107