Jak przechwycić kod błędu

Nie wiem jak skonstruować funkcje, która uruchomiona wraz z tworzeniem aplikacji przechwytywałaby wszystkie kody błędów i jako "errormessage", czyli pod postacią opisu błędu zapisywałaby ją do pliku.

Próbowałem użyć SysErrorMessage(GetLastError) w takiej konstrukcji:

var blad:string;
try
...........

except
blad:=SysErrorMessage(GetLastError);
end;

ale zawsze zmienna blad zwierala informację, że "operacja wykonana pomyślnie".
Dodam, że "wgrałem sobie w D7 polski opis błędów.

Chciałbym stworzyć procedurę (funkcję) rezydentną, która działałaby globalnie w całej aplikacji

a nie tylko w konstrukcji try....except

Proszę o podpowiedź.
Za każdą pomoc z góry dziękuję.

tworzysz sobie procedurę:

procedure blad(Sender: TObject; E: Exception);

i podpinasz do zdarzenia: Application.OnException. Opis błędu wewnątrz procedury odczytujesz za pomocą: Exception.Message

w JEDI jest takie coś - zobacz sobie to (przy odpowiednio zrobionej kompilacji wskazuje nawet linijkę, w której wystąpił błąd)

do powyższego
jak już to E.Message

Ranides napisał(a)

tworzysz sobie procedurę:

procedure blad(Sender: TObject; E: Exception);

i podpinasz do zdarzenia: Application.OnException. Opis błędu wewnątrz procedury odczytujesz za pomocą: Exception.Message

OK.
Sprawdziłem działa prawidłowo....
ale tylko operacji nie ujętych w konstrukcje try...except.
Tzn. jeśli jest jakaś operacja ujęta w try...except, to błąd nie jest widoczny w Application.OnException, czyli
komunikat brzmi: "Operacja wykonana pomyślnie"

Ktoś powiedziałby, że nie używaj try...except, ale muszę obsłużyć wyjątki, oprócz zapisania błędu do pliku i uniknięcie wszystrkich konstrukcji w aplikacj try...except jest nie możliwe.

I mam jeszcze jedno nieskromne pytanie....
Jak pobrać nazwę elementu, którego błąd dotyczy, bo chciałbym zapisywać informacje o błędach w postaci:
<data> <element> <błąd>

jak coś masz w try except to tak jakby tego nie było
co rozumiesz pod "nazwa elementu"

Misiekd napisał(a)

jak coś masz w try except to tak jakby tego nie było
co rozumiesz pod "nazwa elementu"

ok..
już poradziłem sobie z try...except

po prostu konstrukcja try...except "kasuje numer błędu"

i należy użyć takiej kostrukcji

try
....
except
raise Exception.create(...);
end;

I tak zdefiniowany błąd przechwyci procedura Application.OnExcept

Pod hasłem "element" miałem na myśli nazwę komponetu.
Na przykład gdy błąd związany jest z komponentem Edit1, to w pliku zapisuje się informacja o tym elemencie.

var
i,g:integer;

begin
try
i:=strtoint(Edit1.Text);
g:=strtoint(Edit2.Text);
except
raise Exception.Create('Edit1-> Błąd przy konwersji');
end;
end;

Skąd mam wiedzieć, którego komponentu dotyczy błąd, czy Edit1 czy Edit2 ??

ALe nie wiem jeszcze, jak "automatycznie" wychwycić, że to chodzi o Edit1, bo przecież pomiędzy try a except mogę umiećić więcej funkcji czy procedur.

try
....
except
raise Exception.create(...);
end;

to po co Ci w ogóle to try except?

następne
nie da się określić którego komponentu bo błąd nie musi być związany z konretnym komponentem. Możesz co najwyżej sprawdzić, który kompnent miał focusa.

I jak pisałem wcześniej w paczce JEDI masz takie cu, co po wystąieniu błedu pokaże Ci nawet numer wiersza w kodzie, gdzie wystąpił błąd praktycznie wzbogacając Twoją aplikację o 1 lnijkękodu, która i ta doaje się automatycznie :p

Dokładnie - wyjątki są rzucane w powietrze i nikt nie wie skąd i dokąd. Natrafiają na pierwszy blok catch i tam są przechwytywane. Jak wyjątek zostanie przechwycony, to zakłada się, że kod przechwytujący również naprawia sytuację - więc wyjątek nie dociera do ostatniej klamry, jaką de facto jest OnException. Jak chcesz dokładniejszego mechanizmu, to musisz sięgnąć po Jedi.

Do Miśka: konstrukcja Robotixa się przydaje wbrew pozorom. Przejmowanie wyjątku i rzucenie dalej jest używaną praktyką, chociażby właśnie do takich celów. Zagnieżdżone excepty naprawiają sytuację, bo jeszcze wiedzą co się dzieje, ew. dodają do wyjątku informacje - a globalny po prostu zapisuje wszystko do loga. W c++ do ponownego rzucenia dokładnie tego samego wyjątku, który się przejęło, jest nawet konstrukcja: samo throw - bez żadnych argumentów. Nie wiem jak to wygląda w Pascalu - tzn. czy da się rzucić przejęty wyjątek, czy koniecznie trzeba tworzyć nowy obiekt.

znaczy ja rozumiem i stosuję wyłapanie wyjątku i rzucenie nowym np. z polskim komunikatem ale nie widzę sensu wyłapania wyjątku tylko po to, żeby za chwilę go rzucić w niezmienionej postaci. Wyjątek (niewyłapany) to takie coś co mówi userowi, że coś jest nie tak. Natomiast jeśli wyłapujemy wyjątek to jesteśmy świadomi tego, że może on tam wystąpić i go dopuszczamy pod pewnymi warunkami.

Kiedyś robiłem podobnie, tzn każda procedura była w bloku try except i po except zapisywałem do pliku info o wyjątku (tak, bo OnException nie łapie wszystkiego) ale szybko zrezygnowałem. Jest to upierdliwe, zaciemnia kod i nie zawsze chce działać.

Na prawdę podpięcie sobie do aplikacji TExceptionDialog'a z JEDI jest dużo prostsze i bardziej efektywne

Misiekd napisał(a)

znaczy ja rozumiem i stosuję wyłapanie wyjątku i rzucenie nowym np. z polskim komunikatem ale nie widzę sensu wyłapania wyjątku tylko po to, żeby za chwilę go rzucić w niezmienionej postaci. Wyjątek (niewyłapany) to takie coś co mówi userowi, że coś jest nie tak. Natomiast jeśli wyłapujemy wyjątek to jesteśmy świadomi tego, że może on tam wystąpić i go dopuszczamy pod pewnymi warunkami.

Kiedyś robiłem podobnie, tzn każda procedura była w bloku try except i po except zapisywałem do pliku info o wyjątku (tak, bo OnException nie łapie wszystkiego) ale szybko zrezygnowałem. Jest to upierdliwe, zaciemnia kod i nie zawsze chce działać.

Na prawdę podpięcie sobie do aplikacji TExceptionDialog'a z JEDI jest dużo prostsze i bardziej efektywne

po prostu piszę aplikacje do komunikacji z urządzeniami w sieciach szeregowych (które czasami sieją głupoty) i nie mogę sobie pozwolić na to, żeby głui błąd spowodowała zatrzymanie procesu produkcyjnego czy też wylanie 2 ton czekolay ze zbiornika (co już mi się zdażyło), dlatego też muszę obsłużyć taki wyjątek i warto byłoby wiedzieć, że taki fakt miał miejsce.
Nie jest mi do tego wcale potrzebna informacja, w której linijce kodu wystapił błąd tylko po prostu jaka operacja niepowiodła się.

Jak rozumiem wspomniana kotrolka JEDI nie wchodzi w skład podstawowy D7 Ent.??

nie występuje