Discussion :

[joc02]

Bonjour,

J'ai un code qui fonctionnait bien jusqu'à aujourd'hui. Pour de multiple raisons, j'utilisais un exe incluant tous les BPL.
Maintenant j'ai décidé de construire mon projet en cochant la case "lié les packages d'execution".

Par contre ce code ne marche plus. Le GetLastError retourne toujours "0" au lieu, par exemple de "32".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
procedure TForm1.Button1Click(Sender: TObject);
Var
   Stream: TStream;
   iError : integer;
begin
   Stream := nil;
   iError := -1;
   try
      try
         Stream := TFileStream.Create('d:\toto.docx', fmOpenRead);
      except
         begin
            iError := GetLastError;
         end;
      end;
   finally
      if Assigned(Stream) then
         Stream.Free;
   end;
 
 
   showmessage('Erreur : ' + inttostr(iError));
 
 
end;

Peux importe les packages que je mets, dès qu'ils sont activés, je n'ai plus mon code d'erreur

[Andnotor]

Ca ne peut pas marcher, même sans bpl.

GetLastError renvoie le dernier code d'erreur ET le remet à 0.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
begin
  SetLastError(999);
  ShowMessage(IntToStr(GetLastError)); //999 au 1er appel
  ShowMessage(IntToStr(GetLastError)); //0 au deuxième
end;

Et puisque TFileStream génère l'éventuelle exception sur OpenFile en récupérant l'erreur par GetLastError, tu ne peux plus l'utiliser dans ton gestionnaire d'exception.

Deuxième chose, l'objet n'est pas instancié si une exception survient dans son constructeur. Ce try..finally est soit inutile, soit mal placé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
procedure TForm1.Button1Click(Sender: TObject);
Var
   Stream: TStream;
begin
  try
    Stream := TFileStream.Create('d:\toto.docx', fmOpenRead);
 
    try
      ...
    finally
      Stream.Free;
    end;
 
  except
    on E:Exception do
      MessageDlg(E.Message, mtError, [mbOk], 0);
  end;
end;

[ShaiLeTroll]

Dommage, le EFOpenError ne contient pas le code d'erreur mais il contient au moins le message détaillé sur le principe expliqué par AndNotOr

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
      except
         on EFOE: EFOpenError do
            sError := EFOE.Message;
      end;

[joc02]

Je ne suis pas sûr de comprendre votre explication sur le GetLastError. Ce que je crois comprendre, c'est que vous me dite que le GetLastError est déjà appelé dans le gestionnaire d'exception du TFileStream.Create.

Essayer le projet sans cocher les BPL et vous verrez que vous aurez le code "32" qui va ressortir. Donc pourquoi n'est il pas remis à 0 dans ce cas ?

on EFOE: EFOpenError do
sError := EFOE.Message;

Effectivement on se rapproche d'une solution, mais sans être sûr de la cause du problème. Le message ne sera pas identique sur les machines étrangères.

Je suis d'accort sur le try except et la construction petit projet fait à a va vite pour le forum

[ShaiLeTroll]

GetLastError gère une erreur par thread, normalement le BPL se comporte un peu comme une DLL et entre un EXE et DLL, cela partage le même "LastError"
Sur XE2, j'ai bien le comportement que tu observes

Pour moi GetLastError ne remet pas à Zéro dans tous les cas !
J'ai l'impression que GetLastError ne remet à zéro que si c'est le module appelant qui lit la valeur, du moins c'est une observation et un comportement aussi variable n'a rien d'enchanteur :
une DLL utilise SetLastError puis lit GetLastError, il y a une remise à zéro
un EXE utilise SetLastError puis lit GetLastError, il y a une remise à zéro (voir code de AndNotOr)
une DLL utilise SetLastError puis l'EXE appelant lit GetLastError, il n'y a pas de remise à zéro parce que ce n'est pas le même module entre le Set et le Get
Le BPL étant une sorte de DLL à la sauce de Borland, cela s'applique probablement

Dans notre exemple, la DLL qui définie LastError c'est kernel32 et l'EXE lit le GetLastError, et peut le lire autant de fois que souhaité
Si l'on passe en mode BPL, la DLL kernel32 définie le LastError, le BPL lit le GetLastError (et là faudrait faire son propre BPL pour tester si il y a reset ou pas) et enfin l'EXE lui c'est trop tard pour lui pour relire le GetLastError

En débogage, je perds le GetLastError au niveau de _RaiseExcept CALL RaiseList quelque par dans KERNELBASE.TlsGetValue ?
Ce chemin n'est emprunté qu'en mode BPL séparé, en mode intégré, cela passer par @GetTls et cela ne touche pas "LastError"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Var
   Stream: TStream;
   iError, iError2 : integer;
begin
   Stream := nil;
   iError := -1;
   iError2 := -1;
   try
      try
         Stream := TFileStream.Create('d:\toto.docx', fmOpenRead);
      except
         on E: Exception do
         begin
           iError := GetLastError;
           iError2 := GetLastError; // il est toujours défini
         end;
      end;
   finally
      if Assigned(Stream) then
         Stream.Free;
   end;
 
 
   showmessage('Erreur : ' + inttostr(iError) + '  : ' + inttostr(iError2));
 
end;

[Andnotor]

GetLastError renvoie le dernier code d'erreur ET le remet à 0.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
begin
  SetLastError(999);
  ShowMessage(IntToStr(GetLastError)); //999 au 1er appel
  ShowMessage(IntToStr(GetLastError)); //0 au deuxième
end;

Effectivement, je dis des conneries
C'est ShowMessage ici qui le force à 0.

[Jipété]

GetLastError renvoie le dernier code d'erreur ET le remet à 0.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
begin
  SetLastError(999);
  ShowMessage(IntToStr(GetLastError)); //999 au 1er appel
  ShowMessage(IntToStr(GetLastError)); //0 au deuxième
end;

Effectivement, je dis des conneries
C'est ShowMessage ici qui le force à 0.

Pas d'accord, d'un point de vue sémantique : ShowMessage ne force rien du tout, c'est juste que le 1^er ShowMessage s'exécute correctement en affichant 999, ne génère pas d'erreur, donc, et du coup le 2^nd ShowMessage affiche 0 parce que GetLastError remonte 0 parce qu'il n'y a pas eu d'erreur à l'instruction précédente.

[Andnotor]

Et comment pourrait-il valoir 0 s'il n'y a pas de SetLastError(0) quelque part ?

[Jipété]

Et comment pourrait-il valoir 0 s'il n'y a pas de SetLastError(0) quelque part ?

Ben je sais pas trop, mais il se trouve que j'ai dans un coin le Dialogs.pas de D2005 et n'ai rien trouvé dedans à partir de ShowMessage et jusqu'à function CreateMessageDialog(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons): TForm;...

En fait, je pense que le fonctionnement interne et de bas niveau est un peu comme ce qu'on voit sous Linux : toute commande (que ce soit un binaire stand-alone ou une fonction [bien écrite !] dans un script) renvoie un code de fin d'exécution, libre à l'utilisateur de le lire ou pas.
Dans un script, je peux par exemple écrire cp src dst (et je vais à la catastrophe) ou err=cp src dst et ensuite tester la valeur de err et agir en conséquence.
Un peu ce que fait GetLastError, nan ?

[Andnotor]

Il y a plusieurs appels pouvant influer sur le code d'erreur : GetFileVersionInfoXXX, LoadString, GetModuleFileName, ce dernier au minimum forçant (je persiste) ERROR_SUCCESS (0).