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 :
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.
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.
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 :
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 :
On peut plutôt déclencher une erreur utilisateur (G_L_ERR_USER) :
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é.
Deux types d’erreurs peuvent être déclenchées :
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+
Précédemment, j’utilisais cette méthode classique :
VB:
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 SubElle a comme inconvénient le fait que le programme ne sait pas si une erreur est survenue dans une sous-procédure appelée.
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.
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
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 :
VB:
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
VB:
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
'...
'...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.
VB:Err.Raise G_L_ERR_CRITICAL, , "Le fichier '" & l_s_filePath & "' n'existe pas."
- 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.
- 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
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+
Dernière édition:
