Discussion :

[keryss]

Bonjour,

Je cherche un moyen "propre" pour annuler une exception dans un While et continuer le traitement.

Mon code ressemble à cela :

Code :

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

1
2
3
4
5
6
7
8
9
While ()
{
... Mes instructions
}
catch (...)
{
 ... Inscrit exception dans une log
 ==> 'Reprend le traitement While à l''occurence suivante'
}

Le catch est indispensable pour remonter l'erreur et l'inscrire dans une log, mais je souhaite continuer le traitement. En effet je boucle sur plusieurs centaines de milliers d'enregistrements dans mon While et il ne doit pas s'arrêter si un pb survient sur 1 seul enreg en plein milieu par exemple. Néanmoins l'info du plantage doit être tracé pour pouvoir relancer le traitement uniquement sur l'enreg qui a posé pb.

Une idée ?

Merci d'avance,

[tomlev]

mets le try/catch dans le while :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
while (condition)
{
    try
    {
        // ... Mes instructions
    }
    catch(...)
    {
        // ... Inscrit exception dans une log
        // ==> 'Reprend le traitement While à l''occurence suivante'
    }
}

[nah666]

Enfin si tu 'catch' a tous les coups et que tu continue, ton exception est inutile.

Code :

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

1
2
3
4
5
6
7
8
 
While(condition)
{
  if(doJob() == ERROR)
  {
     log();
  }
}

Après il est possible que tu passe par une library externe qui envoie une exception, mais sauf contrainte forte de ce genre, il vaut mieux éviter les levées d'exceptions inutiles.

[playfone]

tomlev => Le programme va quand même s’arrêter dans le catch je me trompe ?

EDIT : Merci de la précision Nathanael

[Nathanael Marchand]

Si tu ne fais pas de throw dans le catch non il continuera la boucle

[keryss]

ok merci à vous, je vais effectivement tenter de mettre le try/catch dans le while... J'avais pas pensé à cela effectivement.

Je relance et je vois

Merci !

[nah666]

Oui mais ce n'est pas la solution 'propre' comme tu le demandais en début de post.

[tomlev]

Oui mais ce n'est pas la solution 'propre' comme tu le demandais en début de post.

Euh... et pour toi la solution propre c'est d'utiliser un code de retour plutôt que d'intercepter l'exception ?
Dans ce cas autant programmer en C

[nah666]

@Tomlev

Je peux me planter, mais il me semble avoir compris qu'on est dans un flot d’exécution normal, qu'il peut y avoir des erreurs dans les données traitées dans la boucle.

A priori on veut pouvoir (via log) retrouver cet enregistrement pour plus tard.

Rien pour moi "d'exceptionnel" dans le sens imprévisible d'un point de vue développement.

Les exceptions ne doivent pas être utilisées pour gérer la logique applicative, mais justement pour les cas qui ne sont pas maîtrisés par l'application.
Du coté performance, on sait aussi que les exceptions coutent cher.

http://stackoverflow.com/questions/4...void-exception

Euh... et pour toi la solution propre c'est d'utiliser un code de retour plutôt que d'intercepter l'exception ?

Oui :

Je prefere :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
If(doJob())
{
  return theReturn;
}
else
{
  log(getErrorString());
  return getEmptyResult();
}

a :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
try
{
   doJob();
}
catch
{
   log(getErrorString());
   return getEmptyResult();
}
  return theReturn;

[tomlev]

Ca dépend des cas en fait... D'une manière générale, je suis d'accord qu'il vaut mieux éviter de lever des exceptions si on peut faire autrement, notamment dans du code où les performances sont critiques. Mais dans un processus métier complexe, c'est souvent le moyen le plus pratique pour faire remonter une erreur à un niveau supérieur, et c'est beaucoup plus propre et mieux structuré que d'utiliser un code de retour.

En plus, dans l'exemple que tu donnes, c'est quoi cette méthode getErrorString ? Elle n'a aucun lien direct avec l'opération qui a déclenché l'erreur, comment fais-tu pour être sûr que les données qu'elle renvoie sont bien liées à l'opération qui a échoué ? Avec les exceptions, ces questions ne se posent pas.

Mais évidemment, il faut pas en abuser... Par exemple tu vas pas t'amuser à catcher des NullReferenceException : il vaut mieux vérifier manuellement si la variable est null (exemple un peu caricatural, certes).

[nah666]

c'est souvent le moyen le plus pratique pour faire remonter une erreur à un niveau supérieur

Oui pour le niveau supérieur (dans ce cas nous somme dans le même niveau applicatif et même dans la même méthode).

c'est souvent le moyen le plus pratique pour faire remonter une erreur à un niveau supérieur, et c'est beaucoup plus propre et mieux structuré que d'utiliser un code de retour.

Une fois de plus, si c'est le flot normal de ta logique applicative il est (fortement) recommandé d'éviter l'utilisation d'exceptions, je sais néanmoins que beaucoup de dev préfèrent utiliser les exceptions car plus 'pratique', ce qui ne veut pas forcement dire propre .

Mais évidemment, il faut pas en abuser...

Oui je pense que la règle absolue reste toujours le bon sens
C'est aussi ce que j'aime dans ce métier c'est que chacun a une approche différente et il y a souvent plusieurs bonnes solutions

[brachior]

Une fois de plus, si c'est le flot normal de ta logique applicative il est (fortement) recommandé d'éviter l'utilisation d'exceptions

Ça implique que le type de tes erreurs correspond au type de retour "normal" de ta méthode.
Tu te retrouves souvent avec le problème de la méthode atoi du C.
Elle renvoie 0 en cas d'erreur, et un entier sinon.
Comment déterminer qu'une erreur est apparue ? (rappel : 0 est un entier ^^)

Les exceptions pallient se problème ...

[meziantou]

Ça implique que le type de tes erreurs correspond au type de retour "normal" de ta méthode.
Tu te retrouves souvent avec le problème de la méthode atoi du C.
Elle renvoie 0 en cas d'erreur, et un entier sinon.
Comment déterminer qu'une erreur est apparue ? (rappel : 0 est un entier ^^)

Les exceptions pallient se problème ...

Tu n'as pas forcément besoin des exceptions pour faire ça.
Tu peux envisager d'avoir des arguments en ref ou en out (comme pour les TryParse).

[brachior]

Tu n'as pas forcément besoin des exceptions pour faire ça.
Tu peux envisager d'avoir des arguments en ref ou en out (comme pour les TryParse).

Je dis pas, c'est ce que fait la méthode strtol en C qui est sensée être utilisée à la place de atoi ^^
Mais bon ^^ Je trouve que ça rend la chose plus compliquée à gérer ...
Et pas forcement approprié à la lecture du code et sa compréhension ...
switch ou imbrication de if ... else ...
Mais c'est mon point de vue ^^

[kheironn]

J'arrive un peu tard sur ce sujet, mais je ne suis pas d'accord avec l'emploi du code de retour.
Si tu as une méthode qui retourne une List<zozo>, comment tu fais avec ton code de retour ?
Tu passes l'un ou l'autre en paramètre out ? Ou tu utilises le type de retour "tuple" du 4.0 ? Ou tu fais - comme j'ai été obligé de le faire sur un de mes projets - une classe de retour contenant des erreurs, et des types de retour via héritage ?

S'il y a une exception, c'est qu'un truc ne va pas. Il faut la gérer ad hoc ou la propager... c'est le but de l'exception en POO.
Maintenant, les exceptions (catch) étant un peu coûteux en perf, il faut les utiliser à bon escient (euh j'ai un doute sur l'orthographe là !).

J'ai eu, dans ce même projet, l'occasion de faire un foreach (ce qui fini en while un fois compilé ) qui récupérait des tas de retours de méthodes avec des exceptions... qui au final servaient à construire des logs et impliquait des traitements particuliers pour pallier au problème rencontré...