Discussion :

[mioux]

Bonjour.

Est ce que quelqu'un peut m'expliquer l'intérêt d'un tel code ?

Code c# :

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

1
2
3
4
5
6
7
8
try
{
    //....
}
catch (Exception ex)
{
    throw ex;
}

J'ai beau chercher à comprendre, à part perturber le débugger je ne vois pas l'intérêt. Quelqu'un pour m'éclairer ?

[jbrasselet]

Tel quel ce code ne sert à rien.
Le Try Catch permet de récupérer les exceptions faite par le code et de les gérer ensuite.

Il faut éviter si possible de récupérer les Exception. Il vaut mieux tenter de spécialiser le type d'exception à gérer (IOException, FileNotFoundException, etc.)

[bizet]

salut

On suppose que dans ton application, tu n'as pas envie que l'utilisateur final sache que l'application plante car le fichier dans lequel tu veux ecrire rencontre un probleme concernant les droits / fichier déjà ouvert,..

Pour cela tu créé une Exception personnalisée MyException qui renvoie le message d'erreur suivant : "Erreur applicative".

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
 
try
{
   //Acces a mon fichier
}
//Exception qui n'existe pas mais cest juste pr l'exemple.
catch (IOException ex)
{
    throw MyException;
}
//Exception qui n'existe pas mais cest juste pr l'exemple.
catch (FileException ex)
{
    throw MyException;
}
catch(Exception ex)
{
 throw GenericException
}

Les catch sont là pour attraper les erreurs que peut rencontrer ton code qui se trouve dans le try.
throw permet de "créer" une nouvelle Exception que tu peux définir comme tu veux.

[tomlev]

Tel quel, il ne fait rien d'utile, et fait même quelque chose de nuisible vu que throw ex réinitialise la pile de l'exception, si bien qu'on ne sait plus d'où vient l'erreur de départ... il faut faire throw tout court pour éviter ça.

Le seul intérêt d'écrire ce genre de code, c'est pour le debug: tu peux mettre un breakpoint dans le catch pour examiner l'exception

[jbrasselet]

Je ne suis pas vraiment d'accord avec toi tomlev. Pour moi faire un throw tout court ne sert non plus à rien.
Les Try Catch sont assez gourmand en ressources, il faut donc les utiliser à bon escient. Il est inutile de créer un code de gestion d'erreur juste pour dire. Il faut savoir ce que l'on va en faire.

[tomlev]

Je ne suis pas vraiment d'accord avec toi tomlev. Pour moi faire un throw tout court ne sert non plus à rien.

Je n'ai pas dit que throw tout court était plus utile, j'ai juste dit que ça évitait de réinitialiser la pile de l'exception, et donc de perdre des infos sur l'erreur. Mais c'est effectivement tout aussi inutile...

Les Try Catch sont assez gourmand en ressources, il faut donc les utiliser à bon escient. Il est inutile de créer un code de gestion d'erreur juste pour dire. Il faut savoir ce que l'on va en faire.

Ce n'est pas le try/catch qui est gourmand en ressource, mais juste le traitement de l'exception. Tant qu'aucune exception n'est levée, ce n'est pas pénalisant d'avoir un try/catch (*) ; et à partir du moment où une exception se produit, la petite perte de performance n'a plus vraiment d'importance...

(*) du moins tant que le corps du try n'est pas trivial. Si c'est juste 1 ou 2 instructions très simples, on observe une petite différence, qui s'estompe dès que le corps du try est un peu plus complexe

[jbrasselet]

Merci de la précision sur les ressources. ON dirait que je n'avais pas très bien capté le truc

[Er3van]

Et quelque chose d'encore plus utilse, tu redéfinies des exceptions toi même pour gérer les erreurs.

Par exemple :

Code c# :

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

1
2
3
4
5
6
7
8
 
    public class GenericException : Exception
    {
        public GenericException() { }
        public GenericException(string message) : base(message) { }
        public GenericException(string message, Exception inner) : base(message, inner) { }
        protected GenericException(SerializationInfo info, StreamingContext context) : base(info, context) { }
    }

Tu peux aussi définir des Exceptions ayant une signification métier.
Par exemple, dans ton code, tu appelles un WebService pour recherche des infos en base.
Ton WebService, tu le fais gérer plusieurs types d'exception (qui hérite donc d'Exception) :
- DataNotFoundException
- DataBaseNotAvailableException
- ...

Voici à quoi ton code pourrait ressembler :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try {
        String sResult = WebService.GetCustomerInfoByID("123");
}
catch(DataNotFoundException dnfe) {
        MessageBox.Show("Customer does not exist in database :"+dnfe.Message);
}
catch(DataBaseNotAvailableException dbnae) {
        MessageBox.Show("Customer does not exist in database :"+dbnae.Message);
}
catch(Exception e) {
        MessageBox.Show("Other Exception :"+e.Message);
}

A l'inverse, dans ton WebService tu pourrais avoir (exemple avec Entity Framework):

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public static String GetCustomerInfoByID(String cuid)
try {
        using (CustomerEntities context = new CustomerEntities())
        {
               var custom = from i in context.CUSTOMERS where CUSTOMER_ID == cuid select i;
               if (i.ToList().Count == 0) {
                      throw new DataNotFoundException(e.Message, e.InnerException);
               }
               return (custom.First()).Name; // Si ta table CUSTOMER contient un champ Name par exemple
        }
}
catch(Exception e) {
        throw new DataBaseNotAvailableException(e.Message, e.InnerException);
}

Bref, il y a beaucoup de possibilités pour gérer les exceptions !

[mioux]

Ah mais changer l'exception pour l'adapter, je comprends, mais là je reprends un code d'un fait par plusieurs autres équipes, et je trouve sans arrêt

Code :

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

1
2
3
4
5
6
7
8
try
{
     // plein d'instructions
}
catch (Exception ex)
{
    trhow ex;
}

Donc ça confirme ce que je pensais, ça ne sert à rien

Je les supprime au fur et à mesure, parce qu'ils me gênent pour le debug en fait, vu qu'au final je ne sais pas exactement quelle ligne génère l'exception sans décortiquer ma variable ex...

Un try {} catch {} qui n'apporte rien ou qui ne masque rien, n'a aucun intérêt...

[Er3van]

Plutôt que de les supprimer, si tu en as la possibilité (au niveau du temps), je te conseillerai de mettre en place un vrai système de gestion d'exception. C'est vraiment pratique pour la débug, spécialement quand on maintient une application que l'on n'a pas développé !

[istace.emmanuel]

Si je peu me permettre :

Je les supprime au fur et à mesure, parce qu'ils me gênent pour le debug en fait, vu qu'au final je ne sais pas exactement quelle ligne génère l'exception sans décortiquer ma variable ex..

La plupart du temps tu n'auras pas 20 lignes dans ton try (ou alors il faut re-factorer ta méthode selon la logique de découpage une fonction = 1 "action").
Et les exception levées dans ton code te permettent d'identifier ou ça a bugué.
Le try/catch est très très utile. Je dev la plupart du temps en C# mais des fois, je dois dev en C et je peu te dire que c'est une des choses qui fait que je suis bien triste...
Sans compter le fait que tu peux utiliser les exception dans la logique de ton code et les lever manuellement ce qui est assez souvent utile.

Je rejoint a 100% Er3van et te conseil de les garder et même de continuer à les utiliser.

[mioux]

Je les retire, parce que dans 90% des cas, ces try catch sont injustifiés, parce qu'imbriqués, le contrôle, n'est pas fait au bon endroit (enfin de ce que j'en dis).

La plupart du temps, voilà ce que ça donne.

Code C# :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
void Main()
{
  HashTable selectParams = new HashTable();
  selectParams.Add("@var1", "value1");
  selectParams.Add("@var2", 2);
 
  try
  {
    DataTable dt = GetMyDatas(selectParams);
  }
  catch (Exception ex)
  {
    throw ex
  }
}
 
void GetMyDatas(HashTable dataParams)
{
  StringBuilder sb = new StringBuilder();
  sb.AppendLine("SELECT  *"):
  sb.AppendLine("FROM    .....");
  //... avec toute la requête ...//
 
  try
  {
    GetDataTableFromQuery(sb.ToString(), HashTable dataParams);
  }
  catch (Exception ex)
  {
     throw ex;
  }
}
 
void GetDataTableFromQuery(string SQL, HashTable SQLParams)
{
  OleDbConnection con = new OleDbConnection("ConnectionString pour Access, mais dans un fichier de config :D");
  con.Open();
  OleDbCommand command = new OleDbCommand(SQL, con);
  //... et tout le blabla pour génrer les paramètres avec Access ...//
 
  try
  {
    adapter.Fill(table);
  }
  catch (Exception ex)
  {
    throw ex;
  }
 
  return table;
}

3 try catch qui n'apportent rien imbriqués les uns dans les autres, je peux en virer au moins 2, et le 3ème ne devrait pas renvoyer d'erreur, puisque en théorie, tout les contrôles pour que les accès à la base soient corrects ont étés faits, et la requête n'est pas non plus censée être incorrecte...

Oui je sais ça n'empêche pas de faire des try catch quand je fais mon fill

[tomlev]

Si je peu me permettre :

La plupart du temps tu n'auras pas 20 lignes dans ton try (ou alors il faut re-factorer ta méthode selon la logique de découpage une fonction = 1 "action").
Et les exception levées dans ton code te permettent d'identifier ou ça a bugué.
Le try/catch est très très utile. Je dev la plupart du temps en C# mais des fois, je dois dev en C et je peu te dire que c'est une des choses qui fait que je suis bien triste...
Sans compter le fait que tu peux utiliser les exception dans la logique de ton code et les lever manuellement ce qui est assez souvent utile.

Je rejoint a 100% Er3van et te conseil de les garder et même de continuer à les utiliser.

En fait le débat n'est pas sur l'utilité du try/catch, qui est évidemment très utile... la question portait sur l'utilité des blocs catch qui ne font rien d'autre que de relancer l'exception. Et ça c'est effectivement inutile, sauf à la rigueur pour y mettre un breakpoint...

[Er3van]

On est bien d'accord, mais plutôt que de supprimer la ligne, pourquoi ne pas remplacer :

Code c# :

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

1
2
 
throw ex;

par

Code c# :

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

1
2
 
throw new Exception("Erreur in myclass/myfonction :"+e.Message, e.InnerException);

ça ne prend pas beaucoup de temps, et là on sait faire quelque chose avec !

[Arnard]

le throw; est plus pertinent que le throwx new Exception, car tu perds le type de ton exception en forçant à regarder dans Inner... Vouloir identifier le nom de la méthode dans le message est une bonne chose, mais type au moins l'exception (InvalidOperationException, ou une exception personnelle...)

[mioux]

Perso, je suis plus dans des trucs du genre

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#if !DEBUG
try 
{
#endif
    // code avec éventuellement des try/catch pour contrôler mes erreurs
#if !DEBUG
}
catch (Exception ex)
{
    MessageBox.Show("Erreur survenue dans MyFunction");
    // Eventuellement des traces si je suis en phase de débug avec des
    // utilisateurs qui n'ont plus qu'un fichier à me transmettre pour m'aider
    // à localiser l'erreur.
}
#endif

Comme ça quand je suis en débug, le débugger stoppe sur la ligne qui pose problème.

[tomlev]

le throw; est plus pertinent que le throwx new Exception, car tu perds le type de ton exception en forçant à regarder dans Inner... Vouloir identifier le nom de la méthode dans le message est une bonne chose, mais type au moins l'exception (InvalidOperationException, ou une exception personnelle...)

Effectivement, new Exception n'est pas vraiment une bonne idée car le type Exception est beaucoup trop générique. Par contre, si tu as des exceptions métier spécifiques, c'est une option intéressante : du point de vue des couches de plus haut niveau, une exception purement technique comme SocketException ou IOException n'est pas très utile, alors qu'une exception plus fonctionnelle comme DataNotFoundException ou QuotaExceededException est beaucoup plus parlante

[ced600]

Un try {} catch {} qui n'apporte rien ou qui ne masque rien, n'a aucun intérêt...

Masquer une exception c'est masquer un bug sous jacent qui pourra venir t'embeter ailleur un an plus tard : Attention !!!

Oui je sais ça n'empêche pas de faire des try catch quand je fais mon fill

Et pour cause il y a des milliers de raison qui peuvent généré une exception (perte de la connexion, indisponibilité de la base, crash du server, lock sur les tables, incohérences entre les données remontées et la structure de la table, ...)

Mais j'ai déjà vu un autre type de gestion d'erreurs plus bourrin.
Aucun try catch pour un site web, et lorsque l'utilisateur se mange l'erreur sur son navigateur il contact directement le développeur par mail en mettant en pièce jointe un screen shot de la page (qui alors affiche le contenu de l'exception).
Rapide, simple et efficace mais pas forcément à conseiller

[mioux]

Aucun try catch pour un site web, et lorsque l'utilisateur se mange l'erreur sur son navigateur il contact directement le développeur par mail en mettant en pièce jointe un screen shot de la page (qui alors affiche le contenu de l'exception).
Rapide, simple et efficace mais pas forcément à conseiller

J'ai fait exactement la même chose sur mon premier projet en .Net (à la différence près que je ne mettais pas un screenshot mais le message de l'exception et l'état de la pile)

Et aujourd'hui, sur ce programme, j'ai mis un gros MessageBox en cas d'exception non gérée avec le numéro de version dans le titre, et le contenu de la pile dans le message. Mais c'est parce que quand je reçoit des bugs, c'est "Y a un bug là, t'as vu ?" avec un screenshot du message de .Net standard, non déplié, sans informations de comment le reproduire, bref, aucune info...

Et sur le tout dernier programme que j'ai réalisé, tout seul, comme un grand, et surtout sans que personne ne soit passé avant moi, et ben j'ai de vrais try/catch, des messages d'erreurs personnalisés (c'est ça que j'appelle "masquer une information", c'est, par exemple, ne pas montrer le message d'erreur standard de .Net et récupérer le programme pour le remettre dans un état stable et logique, dans le cas de ce fameux programme, c'est pas compliqué ) et un client qui te dit "J'ai un bug quand je fais ça, ça, ça et ça".

[ced600]