Gestion d'erreur optionnelle [Résolu]

Signaler
Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020
-
Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020
-
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é.

5 réponses

Messages postés
14916
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
25 octobre 2020
447
Bonsoir,

c'est quoi l'idée, tomber directement sur la ligne qui plante, ou faire du traitement d'erreur différencié?
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.
Messages postés
14916
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
25 octobre 2020
447
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

Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020

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.
Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020

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 ?
Messages postés
14916
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
25 octobre 2020
447
ex.StackTrace
Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020
>
Messages postés
14916
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
25 octobre 2020

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.
Messages postés
14916
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
25 octobre 2020
447
de rien
Messages postés
182
Date d'inscription
vendredi 1 septembre 2006
Statut
Membre
Dernière intervention
19 juillet 2020

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.