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