alheuredudejeuner

Je travaille régulièrement sur du code écrit, il y a 20 ans.
Il n'y avait pas de bug et pas de gestion d'erreur.
20 ans plus tard après moult migrations, les logiciels plantent en production, sans qu'on n'ait l'information de l'erreur.
Alors ajoutons systématiquement un

Code :

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

try...except

.
Si le code doit planter un

Code :

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

Raise

remonte l'erreur à la méthode parente.
Certains codeurs ne libères pas les objets, sur une petite application, c'est transparent.
Puis l'application grossi, le volumes d'objets créé augmente aussi, et l'application se bloque pendant son fonctionnement.
Alors des le début du codage, celui qui crée un objet est responsable de sa libération.
Ci-dessous, Template de base.

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
procedure TForm1.MaMethode(Sender: TObject);
var
  MonObjet: TMonObjet;
begin
  try
    MonObjet:= TMonObjet.create;
    try
      // Fait quelque chose
    finally
      MonObjet.free;
    end;
  except
    On e:exception do
    begin
      // Fait quelque chose
     //  raise Exception.Create('TForm1.MaMethode erreur; '+e.Message); 
    end;
  end;
end;

Faites attention de ne pas écrire de code qui plante dans le gestionnaire d'exception, je l'ai déjà vu.