Discussion :

[slimjoe]

Bonjour,

Je travaille avec Delphi depuis plusieurs années alors je me sens un peu con de poser ma question...

J'ai testé les fonctions suivantes sous Delphi 7 et Delphi 2007 (projets Win32) et les résultats sont identiques.

Question #1 : Pourquoi est-ce que la fonction ci-dessous me retourne 1 ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
function MonTestInt: integer;
begin
   try
      Result := 1;
      Exit;
   finally
      Result := 2;
   end;
 
   Result := 3;
end;

Question #2 : Si la fonction précédente me retourne 1, pourquoi est-ce que la fonction ci-dessous me retourne '2' (code semblable, mais avec des strings) ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
function MonTestStr: string;
begin
   try
      Result := '1';
      Exit;
   finally
      Result := '2';
   end;
 
   Result := '3';
end;

Question #3 (c'est ma vraie question ) : Pourquoi est-ce que le code suivant affiche l'avertissement « W1035 Return value of function 'MonTestInt' might be undefined » ?

Code :

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

1
2
3
4
5
6
7
8
function MonTestInt: integer;
begin
   try
      Exit;
   finally
      Result := 2;
   end;
end;

Est-ce que je dois changer ma façon de travailler avec les try/finally ?

Merci!

[dehorter olivier]

#1
Après result := 1, tu places un Exit.
Donc tu sort de la fonction directement sans passer par la ligne result := 3.

donc normal

# 2

c'est pas. Il ne suit pas le EXIT

#3 normal
tu sors de la fonction sans attribuer de valeur a la fonction..


les problèmes ne sont pas dans le TRY... FINALLY, mais dans l'utilisation du EXIT.
NB : sans le EXIT, tes 2 premieres reverront systématiquement 3.

[slimjoe]

#1
Après result := 1, tu places un Exit.
Donc tu sort de la fonction directement sans passer par la ligne result := 3.

donc normal

# 2

c'est pas. Il ne suit pas le EXIT

#3 normal
tu sors de la fonction sans attribuer de valeur a la fonction..


les problèmes ne sont pas dans le TRY... FINALLY, mais dans l'utilisation du EXIT.
NB : sans le EXIT, tes 2 premieres reverront systématiquement 3.

Bonjour et merci pour votre aide.

J'aurais dû être plus clair : la valeur attendue pour les deux première fonctions est « 2 ». Ma question est : pourquoi est-ce que le premier exemple retourne « 1 » et le second « 2 » ? Pourquoi est-ce que les deux premiers exemples (très semblables) se comportent de façons différentes ?

Selon l'aide de Delphi, il semblerait que les instructions du finally soient exécutées malgré la présence du exit. Désolé, c'est en anglais :

Exit passes control away from the current procedure, not merely the current block. But Exit does not violate the flow of control dictated by a try..finally construct; if Exit is called inside the try clause, the finally clause is still executed.

Est-ce qu'il y a quelque chose que je ne comprends pas ?

Merci encore!

[dehorter olivier]

non, tu as raison

aide de delphi 2010

Remarque : Exit fait passer le contrôle en dehors de la procédure en cours, pas seulement du bloc en cours. Mais Exit ne déroge pas du contrôle de flux dicté par une construction try..finally ; si Exit est appelée dans la clause try, la clause finally est encore exécutée.

Et en enlevant le exit qui ne sert à rien (mais c'est peut etre une simplification dans une fonction plus complexe)

la, je sèche aussi

[slimjoe]

Et en enlevant le exit qui ne sert à rien (mais c'est peut etre une simplification dans une fonction plus complexe)

C'est malheureusement le cas . J'ai l'habitude de simplifier mes exemples au maximum pour éliminer les facteurs variables.

Je crains sincèrement que Delphi bousille mes finally... J'aimerais beaucoup qu'on me démontre le contraire... Quelqu'un a une idée ?

[Paul TOTH]

C'est un joli bug lié à l'optimisation comme le montre le warning !

[Franck SORIANO]

Celui là, il fallait le trouver

Comme l'a indiqué Paul TOTH, du fait du result := 3 juste en dessous, l'optimiseur pense que le result := 2 ne sert à rien et élimine le code en question.

Je viens de faire le test avec la fenêtre CPU, on voit bien qu'après le Exit, le finally est bien exécuté. Par contre, il n'y a aucun code généré pour l'affectation du résultat.

Si on enlève le result := 3, le résultat est bien 2 !

Ce qui est étonnant, c'est qu'on a le même résultat, même en désactivant les optimisations.

[tourlourou]

Lazarus me dit 2 pour les codes #1 et #2 : ouf !

Et ne met pas de warning pour le #3

Maintenant, si on veut ergoter, le code qui suit le finally ne peut jamais s'exécuter (hormis Label et GoTo, pê) et n'a donc pas lieu d'y être...

Pour qu'il s'exécute, il faut un code du type :

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
function MonTestStr(a: integer): string;
begin
   try
    try
      if a<0
      then raise Exception.Create('négatif !')
      else Result := '1';
      Exit;
    except
      on E: Exception
      do ShowMessage(E.Message);
    end;
   finally
      Result := '2';
   end;
   Result := '3'; // si a <0 car l'exception saute le Exit !
end;

[guillemouze]

c'est une vieille feinte (pour palier à un bug, il faut bien feinter), mais ce que je fais pour forcer a linker des fonctions pour utiliser dans l'evaluateur (sinon il compile pas les fonctions, le ) c'est un truc du genre

Code :

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

1
2
3
4
5
 
if IsZero(1) then //le compilateur ne voit pas que c'est tjrs false :)
begin
  MaFonctionDeDebug();
end;

donc tu peut utiliser cette "technique" pour ton probleme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
function MonTestInt: integer;
begin
   try
      Exit;
   finally
      Result := 2;
      if IsZero(Result) then sleep(0); //pour le forcer à utiliser le result et donc ne pas eliminer la ligne precedente
      //ou
      if IsZero(1) then Inc(Result); // celle la est valide si ton result peut valoir 0, mais celle d'avant ne fait pas non plus grand chose de plus
   end;
end;

[ShaiLeTroll]

Bonne étude ! slimjoe !
Je pense avoir eu une fois, un problème similaire avec un Result integer, avec un comportement illogique, comme le fait remarque Paul Toth, j'avais aussi un Avertissement !
Hors je ne laisse jamais aucun Avertissement sans le comprendre et le corriger car cela indique souvent une erreur d'algo !
J'ai modifié mon code de façon à ne plus avoir d'avertissement, il me semble que cela avait été une gymnastique comme celle proposé par tourlourou, déclenchement d'exception au lieu d'un code d'erreur !

@tourlourou, le compilateur FreePascal Lazarus est donc moins buggé que celui de Delphi ! Hum !

[tourlourou]

@Shaï : moins de bugs pour le compilo dans Lazarus, je doute ; pour le debugger, je n'en ai malheureusement aucun (dans mon environnement)...

mais ça ne fonctionne pas si mal

mes plus gros problèmes viennent de mon ignorance et des difficultés de trouver les ressources pour les combler en FPC/Lazarus.

je suis issu d'une culture livresque (derrière moi, 1m50 de livres sur une étagère) et j'ai un peu de mal à me contenter de tutos / exemples / posts pas toujours disponibles ou faciles à dénicher !

mais 2 actualités pour moi :
http://lazarus.developpez.com/index/...s-sur-Lazarus/
et
pour continuer de coder avec les pieds...

[slimjoe]

Bonjour à tous et merci pour votre aide.

J'ai effectué des tests avec Delphi XE et il semble que le problème ait été corrigé. Je sais pas pour vous, mais moi ce genre de bug me terrorise... Je me mets soudainement à douter de tous mes try/finally...

Merci encore!

[slimjoe]

Re-bonjour!

Êtes-vous prêts pour un comportement encore plus étrange ? Le code suivant est fonctionnel et retourne 2 tel qu'attendu.

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
function MonTestInt: integer;
 
   procedure SetResult(const AResult: integer);
   begin
      //Cette procédure n'est jamais appelée
      Result := AResult;
   end;
 
begin
   try
      Result := 1;
      Exit;
   finally
      Result := 2;
   end;
 
   Result := 3;
end;

J'étais à adapter le truc de guillemouze dans mon projet en me disant qu'au lieu de faire une procédure quelconque, je pourrais m'en servir pour affecter la valeur de retour quand je me suis rendu compte que je n'ai même pas besoin d'appeler ladite procédure. La déclarer suffit (en autant que j'affecte Result).

[guillemouze]

Etrange effectivement. Ce que je subodore, c'est que ce cas la est "trop complexe" pour qu'il puisse optimiser sans risquer de casser le comportement dans certaines situations.
Et il ne les compile vraiement pas les lignes de ta procedure interne (pas de petit point bleu) ?

[slimjoe]

Et il ne les compile vraiement pas les lignes de ta procedure interne (pas de petit point bleu) ?

Non, pas de point bleu :



Sans la procédure :

[GoustiFruit]

Excusez-moi mais à l'origine, la fonction est mal codée, en toute logique il faudrait avoir...

Code :

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

1
2
3
4
5
6
7
8
9
10
function MonTestInt: integer;
begin
  Result := 3;
  try
    Result := 1;
    Exit;
  finally
    Result := 2;
  end;
end;

C'est-à-dire initialiser Result avant de faire les traitements dans un try/finally qui peut comme son nom l'indique, foirer. Ou bien ?

[Andnotor]

Disons que le résultat n'est pas identique. Dans ton codage, Result vaudra toujours 2 alors que dans le premier cas, il vaudra 3 si la fonction échoue et 2 si elle réussi

[slimjoe]

Excusez-moi mais à l'origine, la fonction est mal codée, en toute logique il faudrait avoir...

Code :

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

1
2
3
4
5
6
7
8
9
10
function MonTestInt: integer;
begin
  Result := 3;
  try
    Result := 1;
    Exit;
  finally
    Result := 2;
  end;
end;

C'est-à-dire initialiser Result avant de faire les traitements dans un try/finally qui peut comme son nom l'indique, foirer. Ou bien ?

Disons que le résultat n'est pas identique. Dans ton codage, Result vaudra toujours 2 alors que dans le premier cas, il vaudra 3 si la fonction échoue et 2 si elle réussi

Dans mon exemple, « Result := 3; » ne sert effectivement à rien (la fonction ne retournera jamais 3). C'est juste que le bug ne semble survenir que si j'affecte « Result » après le « finally ».

[Montor]

Pour la troisièmement question c'est normal puisque une variable locale dans la section finally /end
doit âtre initialisée avant l'exécution de try/finally
dans l'excemple suivant montre la pertinence de cette démarche

Code :

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

1
2
3
4
5
6
7
 
   Result:= TFilestream.Create('fichierIntrouvable',fmOpenRead);
   try
 
   finally
      Result.Free
   end;

Par contre le code suivant prdt une violation d'access

Code :

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

1
2
3
4
5
6
 
   try
        Result:= TFilestream.Create('fichierIntrouvable',fmOpenRead);
   finally
      Result.Free
   end;

Voici une aurte situation ou le compilateur ne donne aucun avertissent concernant
la valeur de retour

Code :

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

1
2
3
4
5
6
7
8
var L:integer = -1;
function rrr():integer;
begin
 for Result := 0 to L do
       if Result = 5  then
           break;
 
end;

[slimjoe]

Pour la troisièmement question c'est normal puisque une variable locale dans la section finally /end
doit âtre initialisée avant l'exécution de try/finally

Ça fait du sens. Merci .