gestion d'erreur optionnelleRésolu

Question

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

Whismeril · Answer

Bonsoir,

c'est quoi l'idée, tomber directement sur la ligne qui plante, ou faire du traitement d'erreur différencié?

mgdsoftware · Answer

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.

Whismeril · Answer

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 · Answer

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 ?

MGD Software · Answer

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.

Gestion d'erreur optionnelle

5 réponses

Votre réponse

Discussions similaires