Assertions nutzen

Re: Assertions nutzen

Erst recht, nachdem ich heute leidvoll lernen musste, dass man auf Feldsymbole keine Watchpoints legen kann (vor allem in LOOPs). Das ist dann wieder ein großer Pluspunkt für Workareas statt Feldsymbolen - und da ich sperrige Workareas Mist finde, ein großer Pluspunkt für Tabellenkopfzeilen.

adt hat geschrieben:Dafür kann man aber einen WatchPoint auf das Ziel des Feldsymbols (Tabellenzeile, Strukturfeld usw.) legen.

Wie soll das gehen? Der Debugger akzeptiert 7.50-Syntax nicht, so dass ein Watchpoint etwa auf meinetabelle[ 3 ]-MATNR = '12345678' nicht funktionieren wird.

Abgesehen davon ist mir nicht klar, was mir das helfen soll, wenn ich z.B. in einem LOOP AT meinetabelle ASSIGNING FIELD-SYMBOL(<meinetabelle>) stehenbleiben möchte, sobald der LOOP die Materialnummer '12345678' erreicht hat. Normalerweise würde ich da einen Watchpoint auf <meinetabelle>-MATNR = '12345678' anlegen wollen, aber das funktioniert nicht. Mit einer Workarea würde es gehen.

Als einzigen Workaround habe ich da bisher gesehen, vorher im Debugger zu schauen, in welcher Tabellenzeile die gesuchte Materialnummer steht und dann den Watchpoint auf SY-TABIX zu setzen. Das ist aber eine Krücke, und als ich kürzlich eine Schleife hatte, bei der ich innerhalb der Schleife Tabellenzeilen gelöscht habe, war dieser Weg auch verbaut.

Das Hauptproblem hast du bereits angesprochen: Man muss im Grunde vorher wissen, wo hinterher Break-Points nützlich gewesen wären.
Das kann man aber kaum, weil man dann bereits wüsste, welche Fehler auftreten. Und wenn man das vorher weiß, programmiert man gleich anders...

Ein Anwendungsfall bei mir ist das rasche Anlegen bedingter Breakpoints (a.k.a. Watchpoints) im Entwicklungssystem. Ich programmiere in Eclipse, aber die Eclipse-SAPGui-Integration ist so langsam, dass ich es nicht für praktikabel halte, in Eclipse Breakpoints etc. anzulegen und dann das Programm darüber zu testen. Also habe ich parallel ein SAPGui offen. Das aber interessiert sich nicht für in Eclipse gesetzte Breakpoints. Da helfe ich mir oft mit dem BREAK-Befehl (oder genauer: BREAK-Makro). Ein ASSERT als programmierter Watchpoint während der Fehlersuche könnte da auch nützlich sein. Sobald meine Analyse abgeschlossen ist, fliegt er wieder raus. An der Stelle rede ich also von nichts, was im finalen Code verbleiben soll. Die ID brauche ich auch nur deshalb, weil ich der Doku zufolge nur mit ID den ASSERT veranlassen kann, in den Debugger zu wechseln, anstatt mir direkt wegzudumpen.

Watchponts auf Feldsymbole geht mit einem Workaround. Man kann ja einem Breakpunkt eine Bedingung mitgeben

Das wusste ich gar nicht! Unglaublich, was es für mich noch zu lernen gibt. Ich dachte immer, das sei genau der Unterschied zwischen einem Watchpoint und einem Breakpoint, dass ein Watchpoint eine Bedingung hat und ein Breakpoint nicht. Ich wusste zwar, dass man einen Breakpoint etwa auch durch bestimmte Nachrichten auslösen kann, aber dass man da eine gewöhnliche boolesche Bedingung formulieren kann, ist mir neu. Aber ich habe es ausprobiert, und Du hast recht!

Es lohnt halt doch immer wieder, hier zu fragen!