Discussion :

[Gouyon]

Salut

Voilà j'ai une classe de descendante de TObject dont j'ai surchargé le constructeur Create.
Il se peut qu'en fonction de certaines valeurs des paramètres du constructeur l'objet ne puisse pas être créer.
Jusqu'à présent je m'en tirait en utilisant une variable qui indiquait si la création s'était bien passée ou non. Mais j'aimerais que Create renvoie nil dans le cas où la création n'a pas réussie.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
var
MonObj:TObj;
begin
 MonObj:=TObj.Create(p1,p2);
 if MonObj<>nil then
  begin
   {traitement}
  end;
end;

Je me rappelle avoir vu quelque chose là dessus mais impossible de remettre la main dessus .

[Linkin]

Normalement, en faisant une exception, cela marche.

Sinon en utilisant un système, un peu comme une factory.

Code :

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

1
2
3
4
5
6
7
 
function TMaClasse.CreateObject(p1,p2:Integer):TMaClasse;
begin
  Result := nil;
  if VerififationP1 and VerificationP2 then
    Result := TMaClasse.Create(p1,p2);
end;

[Andnotor]

Déclenche une exception dans le constructeur de ton objet et englobe le Create dans un bloc try...except.

edit: Grillé

[Franck SORIANO]

Je me rappelle avoir vu quelque chose là dessus mais impossible de remettre la main dessus .

Tu dois penser à Fail. Mais ça ne peut être utilisé que dans un constructeur d'objet et pas pour une classe :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
  TMonObjet = object
    constructor Create;
  end;
 
constructor TMonObjet.Create;
begin
  if ....
  then Fail;
end;

C'est comme ça que la POO avait été introduite du temps de Turbo Pascal.
Dans Delphi ça fonctionne encore mais on déclare des class à la place des object.
Avec une classe, il faut déclencher une exception.

[Gouyon]

Déclenche une exception dans le constructeur de ton objet et englobe le Create dans un bloc try...except.

Il me semble que c'est quelque chose de ce genre que j'avais vu. Par contre je ne suis pas trop familier des exceptions. Pourrais tu me donner un exemple.
Parce qu'en fait il faut que je génère mon erreur et là je ne sait pas trop comment faire.

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
 
type
  TMonObjet = class(TObject)
    constructor Create;
  end;
 
constructor TMonObjet.Create;
begin
  try
   .....
  Except on E:Exception do
    begin
      ??????????
    end;
 
end;

[Montor]

Code :

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

1
2
3
4
5
6
7
8
9
type
 
 
constructor TMonObjet.Create;
begin
 // if condition_erreur then
  raise Exception.Create('err');
 
end;

utilisation

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var
MonObj:TObj;
begin
try
 MonObj:=TObj.Create(p1,p2);
 
   {traitement}
 
Except on E:Exception do
begin
      ??????????
end;
 
end;

[Gouyon]

Ok merci pour la réponse je teste ça dès que possible.

[RamDevTeam]

Normalement, en faisant une exception, cela marche.

Sinon en utilisant un système, un peu comme une factory.

Code :

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

1
2
3
4
5
6
7
 
function TMaClasse.CreateObject(p1,p2:Integer):TMaClasse;
begin
  Result := nil;
  if VerififationP1 and VerificationP2 then
    Result := TMaClasse.Create(p1,p2);
end;

c'est presque çà.

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
//déclaration =>

type
  TmaClasse = class(Tobject)

   public
         class function CreateObject(p1,p2:Integer):TMaClasse;
   end;

[class  function TMaClasse.CreateObject(p1,p2:Integer):TMaClasse;
begin
  Result := nil;
  if VerififationP1 and VerificationP2 then
    Result := TMaClasse.Create(p1,p2);
end;

Utilisation =>

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
var Myobj : Tmyclasse;
begin
    Myobj := Tmyclasse.createobject(v1, v2);
 
   if not assigned(Myobj ) then
     exit;
 
 
   // traitement
 
end;

[Kaféine]

Perso, j'ai du mal avec le fait que la création de l'objet puisse renvoyer nil...
Et donc je me pose des questions existentielles.
pourquoi la construction d'un objet devrait échouée?
N'est il pas plus logique que l'objet soit toujours créé mais que son état soit invalide?
Quelqu'un peut me donner un exemple concret ou on a besoin de ce cas de figure?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
var obj: TMonObj;
begin
  obj := TMonObj.Create;
  try
    if Obj.IsValide then
    begin
      // traitement
    end;	
  finally
    obj.Free;
  end;
end;

sinon parmis les idées fournies, celle de la factory reste la plus séduisante à mon sens.

[Gouyon]

Perso, j'ai du mal avec le fait que la création de l'objet puisse renvoyer nil...
Et donc je me pose des questions existentielles.
pourquoi la construction d'un objet devrait échouée?
N'est il pas plus logique que l'objet soit toujours créé mais que son état soit invalide?
Quelqu'un peut me donner un exemple concret ou on a besoin de ce cas de figure?

Dans mon cas je créer un objet LigneDeVue. Cet objet rassemble l'ensemble des hexagones traversé par une ligne droite entre un hexagone de départ et un hexagone d'arrivée. Or il peut y avoir des cas ou l'une des extrémité (voir les deux) ne permet pas de tracer cette ligne (par exemple elle est hors carte) du coups je préfère ne pas créer l'objet plutôt que de le créer pour ensuite le détruire.

[Franck SORIANO]

pourquoi la construction d'un objet devrait échouée?
N'est il pas plus logique que l'objet soit toujours créé mais que son état soit invalide?

Non, un constructeur est censé creer complètement un objet pour le mettre dans un état valide et parfaitement utilisable.
Si tu acceptes de créer un objet invalide, il faudra ensuite te demander s'il est utilisable avant chaque appel de méthode...

Par contre déclencher une exception est tout aussi simple et valable. Sauf si tu te préoccupe des performances.

[sjrd]

Par contre déclencher une exception est tout aussi simple et valable. Sauf si tu te préoccupe des performances.

C'est quoi cette remarque sur les performances ? Les exceptions n'ont rien d'anti-performant, au contraire. Elles sont bien plus performantes que des tests de validité à chaque retour de méthode et/ou constructeur !

[Franck SORIANO]

L'exception sera plus performante que les tests à la seule et unique condition qu'elle ne déclenche pas !
Sinon, un test ce n'est qu'un test (test que tu feras de toute façon pour savoir si tu dois déclencher l'exception).
Déclencher une exception, c'est avant tout une instanciation d'une classe, la capture du contexte d'exécution, suivi du mécanisme pour déclencher l'erreur en elle même, lui permettre d'arrêter le traitement en cours et de remonter les gestionnaires d'exceptions...
Au final, les exceptions constituent un mécanisme lourd qu'il faut réserver aux erreurs exceptionnelles !

D'ailleurs c'est écrit en toutes lettres dans l'aide en ligne de Delphi :

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.

Les instructions conditionnelles sont souvent le meilleur moyen de tester les erreurs.

Il est préférable de faire un test en amont pour éviter de déclencher une exception plutôt que de laisser l'exception se produire et de la gérer.

De plus, indépendamment de ces considérations, il est courant de surveiller les exceptions qui déclenchent dans une application en production. On enregistre alors automatiquement les exceptions avec leur pile d'appel et toutes les informations utiles au déboggage. L'exception elle-même n'est pas toujours affichée à l'utilisateur .
Puis on surveille ces erreurs pour détecter les disfonctionnements de l'appli. Si tu déclenches des exceptions pour tout et n'importe quoi, pour t'éviter de faire un simple test, ça peut vite devenir problématique.

[Montor]

pourquoi la construction d'un objet devrait échouée?

Si on veut créer un TFileStream en lecture avec un nom de fichier qui n'exist pas le constructeur échoue ... le destructeur est appeler après le déclenchement de l'exception

Code :

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

1
2
3
4
5
6
7
8
9
10
function TMaClasse.CreateObject(p1,p2:Integer; var C:TMaClasse):Boolean;
begin
  C:=nil;
 
  if VerififationP1 and VerificationP2 then
    C:= TMaClasse.Create(p1,p2);
 
  Result :=not  (C = nil);
 
end;

[sjrd]

[...] à la seule et unique condition qu'elle ne déclenche pas !

... ce qui est quand même censé se passer dans 99 % des cas

Sinon, un test ce n'est qu'un test (test que tu feras de toute façon pour savoir si tu dois déclencher l'exception).

Avec une exception, tu feras effectivement ce test une fois. Avec des tests de type if..then, tu peux avoir à retester la même chose à chaque endroit où tu appelles cette méthode, et à chaque endroit qui appelle une méthode qui appelle cette méthode, etc.

Au final, les exceptions constituent un mécanisme lourd qu'il faut réserver aux erreurs exceptionnelles !

Lourd... Tout est relatif. Ce n'est pas si lourd que ça. À nouveau, on retombe dans le débat de l'optimisation. La réponse est toujours la même : d'abord écrire du code lisible. Si, et seulement si, on constate des problèmes de performances, alors commencer à optimiser.

Mais je ne commencerais même pas ma recherche de l'optimisation dans le remplacement des exceptions par des tests en série...

De plus, indépendamment de ces considérations, il est courant de surveiller les exceptions qui déclenchent dans une application en production. On enregistre alors automatiquement les exceptions avec leur pile d'appel et toutes les informations utiles au déboggage. L'exception elle-même n'est pas toujours affichée à l'utilisateur .
Puis on surveille ces erreurs pour détecter les disfonctionnements de l'appli. Si tu déclenches des exceptions pour tout et n'importe quoi, pour t'éviter de faire un simple test, ça peut vite devenir problématique.

Là, je t'accorde bien volontiers tes remarques. Personnellement je n'en suis jamais au point de devoir logguer tous les déclenchements d'exception.

[Kaféine]

Dans mon cas je créer un objet LigneDeVue. Cet objet rassemble l'ensemble des hexagones traversé par une ligne droite entre un hexagone de départ et un hexagone d'arrivée. Or il peut y avoir des cas ou l'une des extrémité (voir les deux) ne permet pas de tracer cette ligne (par exemple elle est hors carte) du coups je préfère ne pas créer l'objet plutôt que de le créer pour ensuite le détruire.

Je suis évidemment pas au courant de toutes les problématiques que tu dois résoudre mais perso je m'assurerais que les extrémités existent avant de créer l'objet LigneDeVue plutôt que celui ci échoue dans sa création.

Non, un constructeur est censé creer complètement un objet pour le mettre dans un état valide et parfaitement utilisable.
Si tu acceptes de créer un objet invalide, il faudra ensuite te demander s'il est utilisable avant chaque appel de méthode...

Par contre déclencher une exception est tout aussi simple et valable. Sauf si tu te préoccupe des performances.

Je suis d'accord et c'est bien ce que j'ai dit. Vouloir renvoyer nil au Create me semble bizarre.
Néanmoins on peut imagine un appel de méthode qui ne peut s'effectuer que si l'objet est dans un état particulier. Un exemple concret est la méthode Post du dataset qui est utilisable que si le dataset est dans certains états.
le but des exceptions c'est de permettre au programme de continuer malgré une erreur.
Une exception dans le constructeur nous dit qu'il y a eu erreur et que malgré tout l'objet sera crée. utiliser cette technique plutôt qu'un test de validite me parait bizarre. c'est tout...

[Franck SORIANO]

... ce qui est quand même censé se passer dans 99 % des cas

A condition de n'utiliser l'exception que pour la gestion des erreurs exceptionnelles...

Lourd... Tout est relatif. Ce n'est pas si lourd que ça.

Comparer le déclenchement d'une exception à un test revient à comparer une fourmie avec un mammouth.

À nouveau, on retombe dans le débat de l'optimisation. La réponse est toujours la même : d'abord écrire du code lisible. Si, et seulement si, on constate des problèmes de performances, alors commencer à optimiser.

Tu dis ça parce que tu n'es pas encore capable d'écrire un code à la fois lisible et performant du premier coup.
Les coûts de l'optimisation suivent une exponentielle. Ce qui signifie qu'il arrive un moment où il faut fournir un effort très important pour obtenir un gain minime.
Mais je préfère le dire dans l'autre sens : La courbe des performances par rapport à l'effort suit un logarithme. Dit dans ce sens, on voit mieux que si on ne fait pas un minimum d'effort, on a très vite fait de se retrouver dans la partie de la courbe où les performances sont en dessous de 0. Où il ne faut pas grand chose pour passer de nulle, moyen et bon. L'optimisation ne commence à devenir couteuse que lorsque tu veux taper dans l'excellent.
Maintenant si on considère que le coût d'une correction est d'autant plus élevé qu'on tarde à la faire... Je ne suis pas sûr que ta philosophie soit un bon calcul.
Réfléchir 30s à ce qu'on fait pour ne pas écrire un non sens en termes de perfs ça ne coute quasiment rien. Et il n'y a aucune raison pour que le code ne soit pas lisible.

Mais je ne commencerais même pas ma recherche de l'optimisation dans le remplacement des exceptions par des tests en série...

Je n'ai jamais dis qu'il fallait le faire. J'ai seulement dit qu'il fallait avoir conscience de l'impacte des exceptions et ne pas les utiliser si on est sur du code critique.

[Franck SORIANO]

le but des exceptions c'est de permettre au programme de continuer malgré une erreur.

Heu pas vraiment.
Au contraire, le but d'une exception est d'arrêter le programme du fait de l'erreur et d'obliger le développeur à gérer l'exception.

Sinon, on a les codes de retour des fonctions en lieu et place des exceptions. Le programme continue malgré l'erreur. Dans 90% des cas, le développeur ne teste pas le code de retour, et le programme continue en croyant que tout s'est bien passé.

[Kaféine]

Au contraire, le but d'une exception est d'arrêter le programme du fait de l'erreur et d'obliger le développeur à gérer l'exception.

Tu gere les exceptions pour justement continuer le programme même si une operation "exceptionnelle" a echoué :\
le code de retour de fonction c'est de la gestion d'erreur "old school" quand on n'avait pas d'objet.
Quand tu veux charger un fichier, tu englobe tout ca dans un try...except pour justement éviter que ton programme ne s'arrete parce que ton fichier n'est pas là....

[sjrd]

Tu dis ça parce que tu n'es pas encore capable d'écrire un code à la fois lisible et performant du premier coup.

Ah ah, je sais bien que je suis jeune mais... Ca fait quand même un bout de temps que je code.
Et avec ma stratégie "lisible puis optimisation", il n'y a eu qu'une seule fois où j'ai dû passer à l'étape optimisation : j'ai alors remplacé complètement l'usage des bitmaps VCL par des Bitmap32 dans l'application en question - ce qui en fait l'a rendue nettement plus lisible et puissante, par la même occasion .

Ah oui, c'est vrai, il y a eu une autre fois. Là c'était un concours d'optimisation en Java pour la résolution de Sudoku... J'ai battu le prof

Les coûts de l'optimisation suivent une exponentielle. Ce qui signifie qu'il arrive un moment où il faut fournir un effort très important pour obtenir un gain minime.
Mais je préfère le dire dans l'autre sens : La courbe des performances par rapport à l'effort suit un logarithme. Dit dans ce sens, on voit mieux que si on ne fait pas un minimum d'effort, on a très vite fait de se retrouver dans la partie de la courbe où les performances sont en dessous de 0. Où il ne faut pas grand chose pour passer de nulle, moyen et bon. L'optimisation ne commence à devenir couteuse que lorsque tu veux taper dans l'excellent.
Maintenant si on considère que le coût d'une correction est d'autant plus élevé qu'on tarde à la faire... Je ne suis pas sûr que ta philosophie soit un bon calcul.
Réfléchir 30s à ce qu'on fait pour ne pas écrire un non sens en termes de perfs ça ne coute quasiment rien. Et il n'y a aucune raison pour que le code ne soit pas lisible.

Beau développement Je sens que je vais le ressortir à certains de mes collègues étudiants D'ailleurs je suis parfaitement d'accord avec toi.

Là où il y a un malentendu, à mon avis, c'est ce que nous appelons de l'optimisation. Pour moi, "réfléchir 30s pour ne pas écrire un non sens en termes de perfs", ce n'est pas ce que j'appelle habituellement de l'optimisation. C'est du... ben du bon sens, justement. L'optimisation au sens où je l'entends, c'est déjà le côté pente raide de l'exponentielle dont tu parles

Donc en fait, il me semble qu'au final, nous sommes parfaitement d'accord l'un avec l'autre.