Revenir en arrière après une exeption! C'est possible?

Version imprimable

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:

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 :)

31/08/2009, 23h44
GSXRider

Je ne vois pas trop l'interet mais rien ne t'empeche de faire des try catch à chaque ligne :mouarf:
01/09/2009, 00h48
Hello_World

Citation:

Envoyé par GSXRider

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

ça alors! et s'il s'agit de 72 000 lignes de code ? qu'est ce qu'on fait ? 72 000 try catch :) ?
01/09/2009, 01h38
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 :aie:

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!
01/09/2009, 05h18
Kaidan
Je vois pas trop l'intérêt ... en plus sur une division par 0.

C'est plus rapide d'écrire :
Code:

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.
01/09/2009, 09h36
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...
01/09/2009, 10h24
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.
01/09/2009, 10h40
Kaidan

Citation:

Envoyé par chrisdot

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.
01/09/2009, 13h09
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 ! :?
01/09/2009, 13h18
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.
01/09/2009, 13h58
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é.
01/09/2009, 14h24
Hello_World

Citation:

Envoyé par 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é.

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

Citation:

Envoyé par 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.

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

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 :)
01/09/2009, 15h20
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, ...)
01/09/2009, 17h25
Hello_World

Citation:

Envoyé par Guulh

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 ...

Citation:

Envoyé par Guulh

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 ! :D )

Citation:

Envoyé par Guulh

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

C'est exactement ça ! :D

Pourquoi pas la nouvelle version de c# supportera un truc comme ça ! :D
01/09/2009, 17h52
Kaidan

Citation:

Envoyé par Hello_World

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

Pitié, jamais. On écrit pas du VB.Spaghetti en C# :mouarf:. 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 !
01/09/2009, 17h55
Guulh

Citation:

Envoyé par Hello_World

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 ?

Citation:

Envoyé par Hello_World

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

Je vais exprimer ma désapprobation :
NON
Hors de question de faire de .Net une plate-forme de bricolo crado comme l'était VB :mrgreen:
01/09/2009, 17h58
Kaidan

Citation:

Envoyé par Guulh

NON

+1 :ccool:.
01/09/2009, 18h21
Hello_World

Citation:

Envoyé par Guulh

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 ;)

Citation:

Envoyé par Guulh

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

Citation:

Envoyé par Kaidan

+1 :ccool:.

Citation:

Envoyé par Kaidan

Pitié, jamais. On écrit pas du VB.Spaghetti en C# :mouarf:. 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 ?
01/09/2009, 19h43
Guulh

Citation:

Envoyé par Hello_World

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 ?

Citation:

Envoyé par Hello_World

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.
07/09/2009, 21h21
Hello_World

Citation:

Envoyé par Guulh

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 .. :ccool: