Gestion d'erreur optionnelle [Résolu]

Messages postés
133
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 avril 2019
-
Bonjour,

N'aimant pas que mes applications se terminent en eau de boudin, je protège les instructions délicates par des blocs try/catch de façon traditionnelle :
try
{
    instruction
    instruction
    ...
}
catch (Exception ex)
{
    // Traitement de l'erreur
    MessageBox.Show(ex.Message);
}


Seulement, lors de la mise au point en mode debug, on passe direct dans le traitement d'erreur et il est difficile de savoir quelle instruction a planté.

J'ai contourné le problème en mettant des instruction conditionnelle sur le try et le catch :
#if !DEBUG
try
#endif
{
    instruction
    instruction
    ...
}
#if !DEBUG
catch (Exception ex)
{
    // Traitement de l'erreur
    MessageBox.Show(ex.Message);
}
#endif


C'est TRÈS lourd !
Et en plus avec ce système il est très compliqué d'utiliser la clause finally.

J'ai eu beau chercher dans la multitude d'options, notamment dans Débogage, je n'ai rien trouvé qui me permettrait d'inhiber le traitement des exceptions, surtout provisoirement. Et rien trouvé sur le Web.

Quelqu'un connaitrait-il une solution plus simple que la mienne pour qu'en debug on ne passe pas dans le traitement d'erreur mais que l'exception bloque l'exécution au niveau de la ligne à problème ?

Merci pour le temps gagné.
Afficher la suite 

Votre réponse

5 réponses

Messages postés
13128
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
20 avril 2019
354
0
Merci
Bonsoir,

c'est quoi l'idée, tomber directement sur la ligne qui plante, ou faire du traitement d'erreur différencié?
Commenter la réponse de Whismeril
0
Merci
L'idée c'est bien de s'arrêter sur la ligne où se produit l'exception.
Pour le traitement différencié, il suffit de mettre un #else à mon système.
Commenter la réponse de mgdsoftware
Messages postés
13128
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
20 avril 2019
354
0
Merci
Non pour le traitement différencier, il faut mettre plusieurs catch.
https://docs.microsoft.com/fr-fr/dotnet/standard/exceptions/how-to-use-the-try-catch-block-to-catch-exceptions

Pour s'arrêter sur la ligne qui plante, je ne connais pas d'autre solution qu'inhiber les try.
La compilation conditionnelle est certes lourde, mais c'est fait une fois pour toute.
Tu peux aussi les commenter / décommenter avec un ctrl+F, mais là il faut le faire à chaque fois.

Sinon, tu mets des points d'arrêt dans les catch et tu regardes la StackTrace, elle te dit le fichier et le numéro de la ligne

MGD Software
Messages postés
133
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 avril 2019
-
En ce qui concerne "Traitement différencié", j'avais compris "en fonction du mode debug ou release", et non en fonction du type d'exception. Je pratique ce dernier sans problème.
Commenter la réponse de Whismeril
Messages postés
133
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 avril 2019
0
Merci
La StackTrace, c'est bien la pile des appels?

J'ai fait un test avec un throw, et sur le point d'arrêt dans le catch, j'y trouve la ligne du catch, puis la ligne de la fonction qui appelle celle où ça plante, mais pas la ligne où se produit l'exception avec le throw.

Ou alors, la StackTrace n'est pas la pile des appels, et alors comment l'obtient-on ?
Whismeril
Messages postés
13128
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
20 avril 2019
354 -
ex.StackTrace
MGD Software
Messages postés
133
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 avril 2019
> Whismeril
Messages postés
13128
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
20 avril 2019
-
Génial! J'ai encore appris quelque chose.
Le dommage, c'est que Console.Write() ne fonctionne toujours pas, j'aurais pu m'en servir. Mais avec un point d'arrêt dans le catch et la fenêtre Execution (ou Automatique), je vais m'en tirer.
Merci.
Whismeril
Messages postés
13128
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
20 avril 2019
354 -
de rien
Commenter la réponse de MGD Software
Messages postés
133
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
16 avril 2019
0
Merci
Dans mon traitement d'erreur (fonction ErrorHandling.TraiteErreur dans le code ci-dessus), je pouvais déjà récupérer le nom de la classe et de la fonction qui provoquait l'erreur.

Grâce à StackTrace et un Regex qui va bien, j'ai pu y ajouter le numéro de ligne, information importante qui me manquait cruellement. Du coup, je n'ai plus besoin des #if pour gérer les exceptions.

Encore merci Whismeril.
Commenter la réponse de MGD Software

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.