🚀 go-pugleaf

W dniu 26.06.2020 o 14:03, apl pisze:
> 
> Drodzy koledzy,
> każdy z was wie, jakim koszmarem jest debugowanie programu, zwłaszcza takiego, do którego sięgamy po wielu latach celem przebudowy nie mówiąc już o cudzych kodach źródłowych.
> Bardzo pomocna w tym przypadku jest znajomość całego łańcucha wołań prowadzących do danego podprogramu.
> W tym poście chciałbym podzielić się bardzo prostym wynalazkiem i poddać go waszej krytycznej ocenie.
> Przypuśćmy, że śledzonym podprogramem jest procedure sub2.
> Mój "chwyt" polega na dodaniu parametru formalnego callChain:string przekazywanego przez wartość oraz na zamieszczeniu na początku treści wykonawczej instrukcji callChain:=callChain+'>sub2'; Zabieg ten należy powtórzyć w każdym podprogramie wołającym wybrany śledzony (tu: sub2) z tym, że zamiast sub2 wpisujemy nazwę podprogramu wołającego z dodatkiem znaku '>' rozdzielającego nazwy w tworzonym łańcuchu. Krytyczne fragmenty treści sub2 obejmujemy instrukcją try except end, gdzie zamieszczamy showMessage informujący o błędzie. W przypadku iteracji, czy rekurencji przydatne będzie proliferowanie wartości zmiennych sterujących - dodajemy wtedy wymagane parametry formalne przekazywane przez wartość. Poniżej zamieszczam maksymalnie uproszczony przykład ilustrujący tę ideę zawierający iterację i rekurencję, stąd parametry i,n:word.
> Tak wzbogacony program daje nieoceniony wgląd w bieżący stan wykonania programu odczytując aktualną wartość callChain. Program niejako buduje się sam, żądając brakujących parametrów formalnych podczas kompilacji.

Może nie rozumiem problemu autora wątku, ale w środowisku Delphi podczas 
debugowania jest dostępne okno "Call stack", które pokazuje ścieżkę 
wywołań. I nie wymaga modyfikacji kodu źródłowego.

Ponadto mamy zewnętrzne narzędzia takie jak madExcept, EurekaLog, 
CodeSite, które wydatnie ułatwiają lokalizację błędów.

Tomek D.