Discussion :

[Teo]

Bonjour

Bonne année 2011 a tous.

Il y a t'il de gros inconveniant a mettre dans toutes les fonctions et procedures
d'un programme(petit ou gros), des blocs Try/Except dans un bloc Try/Finally
genre

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
 
Procedure truc;
Var
  MsgExcept:String;
  ...
Begin
  MsgExcept := '';
  Try
    Try
       code...
       ....
     Except
      MsgExcept := Exception(ExceptObject).Message;
      Exit;
     End;
  Finally
   ...
   bla bla
   ...
  end
End;

Est ce que cela peut beaucoup nuire a la rapidité d'une appli ?

Mercid 'avance pour vos pistes

[Charly910]

Bonjour,

oui cela affecte les performances de l'application - regarde ce que dit l'aide de D7 :

Les exceptions offrent un moyen élégant d'intercepter les erreurs d'exécution sans arrêter le programme et sans utiliser d'encombrantes instructions conditionnelles. Les exigences imposées par la sémantique de la gestion des exceptions se traduisent par une pénalisation au niveau de la taille du code ou des données et au niveau des performances à l'exécution. Il est possible de déclencher des exceptions pour presque toutes les raisons et de protéger pratiquement n'importe quel bloc de code en l'intégrant dans une instruction try...except ou try...finally, mais, en pratique, il vaut mieux réserver ces outils à des situations particulières.

La gestion des exceptions convient aux erreurs qui ont peu de chances de se produire, mais dont les conséquences sont quasiment catastrophiques (le crash d'une application, par exemple) ; aux conditions d'erreurs difficiles à tester dans des instructions if...then ; et quand vous avez besoin de répondre aux exceptions déclenchées par le système d'exploitation ou par des routines dont le code source n'est pas sous votre contrôle. Les exceptions sont couramment utilisées pour les erreurs matérielles, de mémoire, d'entrée/sortie et du système d'exploitation.

Bonne année 2011

Charly

[Andnotor]

S'il n'y a pas d'ittération, le problème de temps est négligeable

Par contre dans le code tel que présenté, l'utilité du bloc try..finally est discutable. Sans parler du Exit inutile !

[Teo]

Merci a vous 2

@Charly910
Je savais que j'avais lut un truc du genre, mais je savais plus où.

@Andnotor
C'est bon a savoir : si peu d'iterat°, pas de risque de lenteur sensible.
En fait, j'instancie souvent des objets, avant le premier Try, d'ou le finally qui doit les detruire.
pour le "Exit" dans l'Except, tu as raison, tel que c'est il est inutil.

Au plaisir

[Andnotor]

A moins d'un Raise dans l'except et l'exception ayant déjà été gérée, il n'y a plus aucun risque. Finally est donc inutile

[Rayek]

A moins d'un Raise dans l'except et l'exception ayant déjà été gérée, il n'y a plus aucun risque. Finally est donc inutile

Ca depend le reste du code, dans le cas de libération d'objet ca arrive souvent de faire cela

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
 
var
  lst : TStringList;
begin
  lst := TStringList.Create;
  try
    Try
    Except on e:Exception do
       // Gestion de l'erreur
       raise;
    end;
  finally
    lst.Free;
  end;
end;

[sjrd]

Eh bien... Je pense que tout ceci mériterait un véritable tutoriel. Il va falloir que je fasse un truc comme ça quand j'aurai le temps

En voilà un (blog) qui, selon moi, ne dit pas bêtises (mais ne dit pas grand chose non plus, il manque plein de trucs) :
http://www.juliencarnelos.com/2006/0...es-exceptions/

[Andnotor]

Le point 1 me plaît bien.
Le point 2 a peu d' (aucun) intérêt. C'est de la logique.
Le point 3 est un point 2 mal réfléchi. Les deux phrases suivantes sont carrément choquantes:

quand une exception incontrôlée survient dans le but d’assainir le programme

et

sur le moment effectivement si une erreur survient le client est content car son application n’affiche pas d’erreur et il peut continuer en apparence.

Assainir le programme lorsqu'il est déjà chez le client. Well... quel manque de rigueur ! De plus,si elle est incontrôlée, comment en déterminer le type exact ? Le point 3 est le point 2 sans aucune reflexion.

Si tu as compris ce sens en mes propos, c'est que je me suis vraiment mal exprimé
Mon approche est très booléenne. Je peux remédier au problème en remplaçant la donnée par une valeur par défaut (point 1) ou l'exécution est interrompue (point 2). Il n'est aucunement question de laisser l'exécution se poursuivre avec une donnée incohérente. C'est la seule chose qui soit vraiment très mal