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;

[Andnotor]

Je mentionnais le Raise et cela dépend bien sûr du code total.
Mais j'aime avoir du code le plus concis possible et si l'état peut être considérer comme stable, finally devient inutile même en cas de destruction d'objet

[sjrd]

Je mentionnais le Raise et cela dépend bien sûr du code total.
Mais j'aime avoir du code le plus concis possible et si l'état peut être considérer comme stable, finally devient inutile même en cas de destruction d'objet

Je ne suis pas d'accord, pour au moins deux raisons :

• Tu peux avoir une erreur non prévue (pas gérée dans le except) - savais-tu à ce propos que Exception n'est pas la classe de base de toutes les exceptions ? Il s'agit de TObject, en fait.
• Le code dans le except pourrait lui-même lever une exception.

[Andnotor]

Je ne dis pas qu'elle doit être systématiquement ignorée, mais que cette 2ème protection est inutile si l'état est stable après l'except. Bien sûr que si ce n'est pas le cas ou qu'on a un doute, autant la laisser

J'admets faire assez peu de test sur un type d'exception précise. En règle générale, c'est un appel qui pose problème et qui doit être sécurisé. Dans mon cas, on E:Exception do me suffit pour récupérer et afficher le message (si besoin). A mon sens, s'il faut tester N exceptions, c'est que le bloc est trop gros ou qu'il manque un ou deux if bien placés. (Mais ça ne regarde que moi )

[sjrd]

A mon sens, s'il faut tester N exceptions, c'est que le bloc est trop gros ou qu'il manque un ou deux if bien placés. (Mais ça ne regarde que moi )

Et à mon sens, un "on Error: Exception do" est une des pires choses que je puisse voir dans un code. Parce que pour moi ça veut dire : je ne sais pas ce que je fais, donc je catche tout comme ça je n'aurai pas de problème

Visiblement, nous avons deux manières totalement différentes d'appréhender la gestion d'erreur

[Andnotor]

...Parce que pour moi ça veut dire : je ne sais pas ce que je fais, donc je catche tout comme ça je n'aurai pas de problème

Pour moi, c'est justement le contraire
Ce serait le cas si on englobait les N lignes de la procédure dans le bloc try except sans aucune réflexion. Peu importe le code et la validité des données, tout cela sera géré (on fera le tri tant bien que mal) plus tard par l'exception.

Je préfère et de loin me dire que telle ou telle fonction peut entraîner un problème et le gérer immédiatement plutôt que d'attendre la fin et me dire : est-ce que...est-ce que...

Prenons un cas simple : StrToInt. Je pourrais tester EConvertError. Mais en sachant que l'erreur de conversion est la seule erreur possible, à quoi bon en déterminer le type exact. Et même si un autre type d'exception existait (sur le signe par exemple), la donnée reste invalide et c'est la seule chose qui m'intéresse. Remplaçons-la par une valeur par défaut ou avertissons immédiatement l'utilisateur de son erreur. Inutile de faire d'autres tests

Il s'agit simplement de savoir où on place la logique. Tu préfères centraliser la gestion des exceptions, je préfère ne pas la laisser se propager plus loin que l'appel incriminé. Quelle est la meilleur solution ? C'est certainement bonnet blanc et blanc bonnet

[popo]

Pour ma part, je trouve que l'utilisation du "finally" et du "if (Assigned())" sont essentielles pour détruire les objets qui ne doivent plus être utilisé.
Supposons qu'on déclare un Objet A dans une procédure QuelqueChose et qu'un autre développeur pour une raison X ou Y décide d'appeler une procédure quelconque dans laquelle, il utilisé A et le détruit on se retrouve avec une grosse violation d'accès par la suite.

Je toujours essayé de faire en sorte que la procédure qui déclare un objet soit également être responsable de sa libération mais ne vivant pas dans le monde des bisounours, il y a toujours un autre développeur qui risque de mettre un gros bordel au milieu de mon code !

Prenons un cas simple : StrToInt. Je pourrais tester EConvertError. Mais en sachant que l'erreur de conversion est la seule erreur possible, à quoi bon en déterminer le type exact. Et même si un autre type d'exception existait (sur le signe par exemple), la donnée reste invalide et c'est la seule chose qui m'intéresse. Remplaçons-la par une valeur par défaut ou avertissons immédiatement l'utilisateur de son erreur. Inutile de faire d'autres tests

Ne serait-il pas préférable de vérifier ça avant que l'utilisateur valide sa saisie !

[Andnotor]

Tu auras beau avoir placé toutes les destructions dans finally. Si l'objet n'existe déjà plus, c'est là que sera généré l'AV et ça ne résoudra pas le problème

If Assigned(), oui pour autant que le pointer ait été reseté (nil). Ce qui implique aussi que la procédure "Quelconque" reçoive le pointeur en paramètre var.

Ne serait-il pas préférable de vérifier ça avant que l'utilisateur valide sa saisie !

Si saisie manuelle il y a, bien sûr. Mais il faut également penser à l'ouverture de fichier, etc. (StrToInt n'était qu'un exemple)

[ShaiLeTroll]

Perso, je me suis fait une fonction RealAssigned qui vérifie qu'un objet existe (vérification de ClassName, ClassType, IsBadReadPtr)

J'en ai eu besoin durant les sections finalization, j'ai eu quelques soucis d'objet partagés par plusieurs listes ou libérés (sans avoir fait de notification)
En corrigeant, certaines maladresses normalement, plus besoin de bidouiller !
Faudrait que je trouve, j'avais encore un cas où je l'utilisais !

je suis aussi adepte du try finally, mais je suis totalement contre l'exemple de Teo, une exception doit être gérée
Gérer une exception, c'est déjà un code correctif genre RollBack
Un éventuel log pour les programmes Batch, Service, ...
Un éventuel redéclenchement, parfois je requalifie l'exception, genre j'ai eu une ESOAPHTTPException, je vais redéclencher EMonWebServiceAMoiError pour savoir quel objet a planter !
Sinon il faut la laisser remonter, elle sera peut-être gérée plus loin !

Je suis comme SJRD, il faut SAVOIR ce que son code fait !

J'ai quelques fonctions genre celle de Log (dans un fichier), dans celle ci, j'ignore les exceptions (un petit OutputDebugString quand même), dans certains cas, on peut fermer les yeux !

En général, les exceptions sont assez rare à part celle de la DB (une bonne encapsulation de la gestion DB et cela ne pose pas de problème), quelques erreurs SOAP et quelques exceptions étranges de Indy genre ESuccessfullException c'est tout de même rare !


Lorsque a un "un autre développeur" qui libère a tord des objets, tu trouves la tasse a café la plus proche et tu lui balances dessus !

Sinon pour StrToInt autant utilise TryStrToInt qui permet de gérer les erreurs sans passer par des exceptions (plus rapide) ou StrToIntDef très pratique aussi

[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