1. Ce site utilise des "témoins de connexion" (cookies) conformes aux textes de l'Union Européenne. Continuer à naviguer sur nos pages vaut acceptation de notre règlement en la matière. En savoir plus.

Gestion des erreurs en VBA

Discussion dans 'Trucs et astuces' démarrée par mromain, 19 Mai 2017.

Par mromain le 19 Mai 2017 à 17:56
  1. mromain

    mromain XLDnaute Barbatruc

    Inscrit depuis le :
    9 Mai 2008
    Messages :
    2497
    "J'aime" reçus :
    44
    Utilise:
    Excel 2013 (PC)
    Bonjour à tous, ce post est dédié à présenter une méthode de gestion des erreurs en VBA que j’utilise depuis quelques temps sur mes projets (professionnels et personnels).

    Précédemment, j’utilisais cette méthode classique :
    Code (Visual Basic):
    Sub Procedure()
        On Error GoTo GestionErreur
     
        'code "métier"
     
     
    QuitterProcedure:
        On Error Resume Next
        'fermer proprement la procédure :
         '  > détruire les objets
         '  > fermer les fichiers ouverts au sein de la procédure
         '  > ...
     
        Exit Sub
     
    GestErreur
        MsgBox "Erreur n° " & Err.Number & " : " & Err.Description
        GoTo QuitterProcedure
    End Sub
    Cette méthode a pour avantage le fait qu’on passe forcément dans la zone QuitterProcedure, qu’une erreur se soit déclenchée ou pas.
    Elle a comme inconvénient le fait que le programme ne sait pas si une erreur est survenue dans une sous-procédure appelée.
    [​IMG]

    Cette contrainte implique le fait qu’il faille, à chaque appel de sous-procédure, contrôler si celle-ci s’est bien déroulée ou pas.

    La méthode présentée ici permet entre autres de résoudre ce problème. Si une erreur survient dans une sous-procédure, celle-ci est renvoyée à la procédure appelante.
    L’affichage de l’erreur en question se fait dans la procédure de plus haut niveau.
    [​IMG]

    Cette gestion des erreurs permet également de tracer dans quelle procédure l’erreur est survenue.
    Dans cet exemple schématisé, on est bien passé dans les zones QuitterProcedure des procédures :
    • Sous-procédure 2
    • Sous-procédure 1
    • Procédure principale
    Vu qu’une erreur est survenue avant son appel, la Sous-procédure 3 n’a pas été appelée.

    Concrètement, voir le code de l’exemple n°1 du fichier joint.

    Un autre avantage de cette gestion des erreurs est qu’on peut choisir d’envoyer des erreurs au sein même du code. Par exemple, plutôt que d’écrire ce code :
    Code (Visual Basic):
    If Dir(l_s_filePath) = vbNullString Then
        MsgBox "Le fichier '" & l_s_filePath & "' n'existe pas."
    Else
        'ouvrir le  fichier et le traiter
         '...
         '...
    End If
    On peut plutôt déclencher une erreur utilisateur (G_L_ERR_USER) :
    Code (Visual Basic):
     l_s_filePath = InputBox("Saisir un emplacement de fichier :", "Saisie utilisateur")
    If Dir(l_s_filePath) = vbNullString Then _
        Err.Raise G_L_ERR_USER, , "Le fichier '" & l_s_filePath & "' n'existe pas."

    'ouvrir le  fichier et le traiter
    '...
    '...
    Dans la pratique, cela permet d’éviter pas mal de fois des boucles If … Else … End If. Quel que soit la procédure d’où est déclenchée l’erreur, elle sera affichée à la procédure de plus haut niveau dans un MsgBox et le code suivant l’erreur ne sera pas exécuté.
    [​IMG]
    Deux types d’erreurs peuvent être déclenchées :
    • les erreurs utilisateur
      Elles sont plus destinées à identifier les erreurs de saisie de l’utilisateur comme dans l’exemple ci-dessus. Lors de leur affichage, une simple MsgBox s’affiche en mode vbExclamation et rajoute "Action annulée" au message d’erreur. Concrètement, voir le code de l’exemple n°2 du fichier joint.
    • les erreurs critiques
      Elles sont destinées à afficher des erreurs personnalisées et plus compréhensibles pour l’utilisateur. Lors de leur affichage, une simple MsgBox s’affiche en mode vbCritical avec la source de l’erreur et sa description de l’erreur. Concrètement, voir le code de l’exemple n°3 du fichier joint.
      Code (Visual Basic):
      Err.Raise G_L_ERR_CRITICAL, , "Le fichier '" & l_s_filePath & "' n'existe pas."
      [​IMG]
    Le seul point noir de cette nouvelle méthode de gestion des erreurs consiste dans sa mise en œuvre. Il faut en effet :
    • ajouter un module dédié à la gestion des erreurs. Celui-ci contient :
      • un type de données particulier (ERR_Mem) utilisé dans la gestion des erreurs pour stocker les informations de l’erreur
      • une fonction StoreErrInfo utilisée dans la gestion des erreurs
      • une procédure DisplayError utilisée pour afficher les erreurs (dans la procédure principale).
      • deux constantes (G_L_ERR_USER et G_L_ERR_CRITICAL) utilisées pour déclencher les erreurs personnalisées.
      Il s’agit du module de code Mod_Err présent dans le fichier joint.
    • gérer deux modèles de gestion des erreurs :
      • celui utilisé dans les sous-procédures, qui sert à renvoyer l’erreur à la procédure appelante
      • celui utilisé dans les procédures principales (celles déclenchées par des actions de l’utilisateur), qui sert à afficher les erreurs
    Au final, avec MZ-Tool bien paramétré, l’utilisation des deux types de gestion d’erreur est assez simple…

    Avec plusieurs mois de recul, je trouve cette méthode très pratique et au final, je l’utilise dans tous mes projets, même les plus petits.

    A+
     

    Pièces jointes:

    Dernière édition: 23 Mai 2017
    Roland_M, David XLD et claude.bonato0 aiment votre message.

Commentaires

Discussion dans 'Trucs et astuces' démarrée par mromain, 19 Mai 2017.

Partager cette page