Discussion :

[Hello_World]

Bonsoir,

je voudrais savoir, s'il y a un moyen de revenir à la ligne du code qui a causer une exception (après avoir traiter l'exception )

J'explique avec un exemple :

Par exemple :

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
 
  try
    { 
z = x / y;
 
e = x+y;
    }
    catch (System.DivideByZeroException dbz)
    {
         MessageBox.Show("Division by zero attempted!");
      z = 1; 
 
    // ici je veux revenir pour exécuter la ligne e = x+y ;
   // Comment faire ? 
 
 
 }

Merci d'avance

[GSXRider]

Je ne vois pas trop l'interet mais rien ne t'empeche de faire des try catch à chaque ligne

[Hello_World]

Je ne vois pas trop l'interet mais rien ne t'empeche de faire des try catch à chaque ligne

ça alors! et s'il s'agit de 72 000 lignes de code ? qu'est ce qu'on fait ? 72 000 try catch ?

[GSXRider]

Niveau perf ça serait intéressant de tester mais j'ai des doutes pour 72 000 try catch...

Après si tu as besoin de vérifier qu'il n'y est aucune exception à chaque ligne de code c'est qu'il y a peut être un problème de conception non ?.. Pour moi c'est comme si dans une interface utilisateur tu controles tout à chaque KeyDown voir même MouseMove..

Après je te dis ça mais je ne connais pas ton contexte d'utilisation

Le débugger est bien capable de le faire donc ça doit être possible mais je penses que si tu arrives à le faire tu vas avoir des pbs de perfs!

[Kaidan]

Je vois pas trop l'intérêt ... en plus sur une division par 0.

C'est plus rapide d'écrire :

Code :

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

1
2
3
4
 
 
z = y == 0 ? 1 : x / y;
e = x + y;

Plus généralement, un bloc try / catch doit être utilisé uniquement pour du code où l'exception peut survenir de façon exceptionnelle (non prévisible) et où l'exécution n'est plus possible ensuite. Si l'erreur est prévisible, alors il faut la vérifier à l'aide de condition, corriger puis continuer l'exécution. Il y a clairement un problème de conception ou d'incompréhension lié à l'utilisation des exceptions.

[kheironn]

Bonjour,
très rapidement, je vous signale l'existance du finally qui exécute du code après le try ou le catch...

Mais tout dépend du code qu'il doit contenir, en général, c'est plutôt du code de libération de ressources qui se trouve dans le finally...

[chrisdot]

Un bloc catch étant un gestionnaire d'exception, il permet de pouvoir corriger une erreur survenue dans le bloc try. C'est donc une stratégie parmi d'autres (if(y==0) z=1; en est une autre).
Effectivement si on choisit cette stratégie, s'il y a 72000 problèmes possibles il faudrait mettre 72000 try/catch. Le grand avantage de try/catch c'est de pouvoir récupérer plus facilement les erreurs et de les hiérachiser. Le code appelant au dessus peut aussi "catcher" les exceptions et donner une nouvelle chance supplémentaire de contre-mesure.

[Kaidan]

il permet de pouvoir corriger une erreur survenue dans le bloc try

Si on peut corriger l'erreur, alors c'est qu'on pouvait la prédire. Et dès lors, l'utilisation d'un try ... catch est inutile.

[Hello_World]

Bonjour,

La division par zéro et les 72 000 lignes de code sont juste des exemples!!
Mon code est très très loin de ces exemples!!

Avant d'ouvrir cette discussion, j'ai pensé à l'idée d'utiliser un try catch pour chaque ligne ! et elle me paraît "déraisonnable " ! Puisqu'à chaque nouvelle ligne , on doit lui ajouter un try catch !

[kineton]

Ne pourrais tu pas extraire dans une fonction le code que tu souhaites exécuter même en cas d'exception, puis l'appeler dans ton finally ? Sinon, il faudrait que tu en dises un peu plus sur le vrai contexte de ton appli.

[Kaidan]

Quel genre de code a besoin d'un try/catch à chaque ligne ?

Tu peux donner un exemple de code ? Parce qu'à mon avis, tu fais complétement fausse route.

De plus, il y a de toute façon des erreurs que tu ne pourras jamais try/catché.

[Hello_World]

Quel genre de code a besoin d'un try/catch à chaque ligne ?

Tu peux donner un exemple de code ? Parce qu'à mon avis, tu fais complétement fausse route.

De plus, il y a de toute façon des erreurs que tu ne pourras jamais try/catché.

Il s'agit d'une centaine de requêtes LINQ

Ne pourrais tu pas extraire dans une fonction le code que tu souhaites exécuter même en cas d'exception, puis l'appeler dans ton finally ? Sinon, il faudrait que tu en dises un peu plus sur le vrai contexte de ton appli.

C'est exactement ce que je suis entrait de faire maintenant depuis le matin !

Normalement c'est bon, j'ai pu résoudre ce problème avec l'utilisation de quelques méthodes à part, et bien sure chaque méthode contient un seul bloc (try catch) ..

Mon problème est résolu, mais le problème d'une façon générale n'est pas résolu ( si on élimine la solution qui consiste à utilisé un (try catch) pour chaque ligne! ) puisqu'il peut arriver qu'on ne peut pas factoriser avec des méthodes !





Merci à vous tous

[Guulh]

Ouala, ça rappelle le "On error resume next" (ou approchant de Visual Basic )


Mais je comprends pas ton souci. Si ton code lève une exception, c'est qu'un truc s'est mal passé. Et je vois pas trop dans quel genre de scénario on serait capable de récupérer de n'importe quel type d'erreur dans n'importe quelle ligne.

Par exemple, suppose que tu chopes via linq des clients, des produits, des factures, et que tu fasses quelque chose de tout ça. Si une de ces trois étapes foire, tu peux pas faire ton traitement ; un seul try catch suffit.

Sans compter que la majorité du code ne lève pas d'exception, l'arithmétique notamment, sauf ton exemple qui est en fait caractéristique, puisque toutes les exceptions soulevées sont évitables, ce qui est pas le cas dès que tu manipules des ressources (fichiers, connexions, mémoire, ...)

[Hello_World]

Mais je comprends pas ton souci. Si ton code lève une exception, c'est qu'un truc s'est mal passé. Et je vois pas trop dans quel genre de scénario on serait capable de récupérer de n'importe quel type d'erreur dans n'importe quelle ligne.

Par exemple, suppose que tu chopes via linq des clients, des produits, des factures, et que tu fasses quelque chose de tout ça. Si une de ces trois étapes foire, tu peux pas faire ton traitement ; un seul try catch suffit.

Et si je dois récupérer par exemple tel attribut de tel table puis effectuer quelques traitements et ensuite on passe à un autre attribut d'une autre table puis effectuer un autre traitement .... et si par exemple une erreur intervient dans le traitement du 1er atttribut ? sachant que tout les traitements doivent être effectués séquentiellement ! C'est ça la problèmatique !


De toute façon, comme j'ai dit, mon problème est résolu avec l'utilisation des méthodes ...

Sans compter que la majorité du code ne lève pas d'exception, l'arithmétique notamment, sauf ton exemple qui est en fait caractéristique, puisque toutes les exceptions soulevées sont évitables, ce qui est pas le cas dès que tu manipules des ressources (fichiers, connexions, mémoire, ...)

Je suis d'accord à propos de l'arithmétique ! (en fait pour mon code, j'ai remplacé quelques (try catch) par if .. else ! )

Ouala, ça rappelle le "On error resume next" (ou approchant de Visual Basic )

C'est exactement ça !

Pourquoi pas la nouvelle version de c# supportera un truc comme ça !

[Kaidan]

Pourquoi pas la nouvelle version de c# supportera un truc comme ça !

Pitié, jamais. On écrit pas du VB.Spaghetti en C# . En plus, l'intérêt est strictement nul. Je trouvais en ASP gonflant à mort, après chaque instruction pouvant provoquer une erreur d'annuler le "On Error Resume Next" et de devoir écrire une tonne de code pour tester si l'exécution s'était bien passée au lieu de faire un simple try/catch qui me remonte directement l'erreur dans une jolie exception !

[Guulh]

Et si je dois récupérer par exemple tel attribut de tel table puis effectuer quelques traitements et ensuite on passe à un autre attribut d'une autre table puis effectuer un autre traitement .... et si par exemple une erreur intervient dans le traitement du 1er atttribut ? sachant que tout les traitements doivent être effectués séquentiellement ! C'est ça la problèmatique !

Alors chacun de ces traitements forme une unité indépendante des autres, que tu peux mettre dans un try-catch. Tu parles de tables de base ? Pourquoi du code interagissant avec la base devrait péter des exceptions si fréquemment ?

Pourquoi pas la nouvelle version de c# supportera un truc comme ça !

Je vais exprimer ma désapprobation :
NON
Hors de question de faire de .Net une plate-forme de bricolo crado comme l'était VB

[Kaidan]

NON

+1 .

[Hello_World]

Alors chacun de ces traitements forme une unité indépendante des autres, que tu peux mettre dans un try-catch. Tu parles de tables de base ? Pourquoi du code interagissant avec la base devrait péter des exceptions si fréquemment ?

Par exemple si on accède à un attribut de valeur null !

De toute façon, ce problème est résolu

Je vais exprimer ma désapprobation :
NON
Hors de question de faire de .Net une plate-forme de bricolo crado comme l'était VB

+1 .

Pitié, jamais. On écrit pas du VB.Spaghetti en C# . En plus, l'intérêt est strictement nul. Je trouvais en ASP gonflant à mort, après chaque instruction pouvant provoquer une erreur d'annuler le "On Error Resume Next" et de devoir écrire une tonne de code pour tester si l'exécution s'était bien passée au lieu de faire un simple try/catch qui me remonte directement l'erreur dans une jolie exception !

Ce que je propose, c'est juste une nouvelle méthode qui nous permet de revenir à l'instruction juste après celle qui a causer l'erreur

Le (try catch) reste le même, sauf, si on veut revenir en arrière, on appelle cette méthode à la fin du catch !

Où est le problème avec ça ?

[Guulh]

Par exemple si on accède à un attribut de valeur null !

C'est un genre d'exception tout a fait évitable, les NullReferenceException. Si tu récupères un objet d'une source de données, c'est a ta charge de vérifier qu'il est non null et de pas appeler des méthodes dessus.
Quel genre d'exception as-tu en tete, dans ta problématique ?

Le (try catch) reste le même, sauf, si on veut revenir en arrière, on appelle cette méthode à la fin du catch !

J'ai pas beaucoup d'info sur la nature de ton projet, mais s'il se contente de récupérer des données d'une source et de les manipuler, il n'a aucune raison en lui même de lever d'exception. Tu risques d'en choper en récupérant les données, donc il est légitime de try catcher ça, mais ton code à toi n'a aucune raison de lever d'exception, s'il est bien fichu.

[Hello_World]

C'est un genre d'exception tout a fait évitable, les NullReferenceException. Si tu récupères un objet d'une source de données, c'est a ta charge de vérifier qu'il est non null et de pas appeler des méthodes dessus.
Quel genre d'exception as-tu en tete, dans ta problématique ?

J'ai pas beaucoup d'info sur la nature de ton projet, mais s'il se contente de récupérer des données d'une source et de les manipuler, il n'a aucune raison en lui même de lever d'exception. Tu risques d'en choper en récupérant les données, donc il est légitime de try catcher ça, mais ton code à toi n'a aucune raison de lever d'exception, s'il est bien fichu.

Bonsoir,
J'ai bien réglé mes problèmes(et pas d'exceptions comme vous avez dit )
Merci à vous tous ..