Jak wiedzą programiści Visual Fox Pro - wyjątek przechwycony w 'catch' nie
zawiera informacji o stack trace (jedynie
podstawowe informacje o miejscu wystąpienia). Dla kogoś, kto równocześnie
programuje w językach takich
jak Java jest to duża strata.

Problem z brakiem informacji o stosie wywołań łatwiej rozwiązać stosując
stary mechanizm
obsługi przez 'on error <funkcja obsługi>'. W takiej sytuacji program po
wystąpieniu błędu
natychmiast wchodzi do funkcji obsługi i jeśli użyjemy wewnątrz ASTACKINFO
to
mamy dokładny pogląd na stos wywołań (trzeba tylko uważać na to, że niektóre
stare
konstrukcje fox pro te informacje zaburzają, np 'read cycle').

Od jakiegoś czasu kombinuję, jak te dwie sprawy połączyć - stosować 'try ...
catch'
ale nie gubić info o stosie. Niestety 'catch...' ma wyższy priorytet niż 'on
error', więc
zastosowanie obu mechanizmów jednocześnie nie daje oczekiwanych rezultatów
- zawsze wpierw jest wejście w 'catch' i informacja na stosie pokazuje
miejsce
przechwycenia wyjątku a nie jego wystąpienia.

Próbowałem zastosować 'catch when ...' do tego, żeby przepuszczać mechanizm
obsługi do funkcji obsługi błędu a potem, po zapamiętaniu stosu spróbować
np.
'retry', żeby wrócił to catch'a (warunek 'when' za drugim razem już zwraca
.T.).
Niestety nic z tego. Po pierwsze sam fakt, że przeszedł przez 'catch when'a
już zmienia informację na stosie, po drugie retry też już nie wraca w
miejsce wystąpienia
błędu - nie ma ponownego wejścia w when'a.

Ktoś wie może, jak problem rozwiązać, ma jakieś pomysły ? Na chwilę obecną
wychodzi mi na to, że jakikolwiek 'catch' na drodze procedur obsług błedów
niszczy informację o stosie a niestety nie wiem, jak zmusić fox'a, żeby
priorytetowo
wskoczył w funkcję obsługi zdefiniowaną 'on error', a dopiero potem zaczął
się
wycofywać po stosie catch'y.