Comprendre On Error Resume Next en VBA et bien l’utiliser

# Comprendre On Error Resume Next en VBA et bien l’utiliser

L’instruction On Error Resume Next représente l’un des mécanismes de gestion d’erreurs les plus controversés en Visual Basic for Applications. Utilisée quotidiennement par des milliers de développeurs dans leurs automatisations Excel, Access et autres applications Office, cette commande suscite autant d’enthousiasme que de méfiance. Son apparente simplicité cache en réalité une complexité technique qui nécessite une compréhension approfondie pour éviter les pièges susceptibles de transformer un code fonctionnel en cauchemar de maintenance. Selon une étude récente de Stack Overflow, environ 43% des erreurs silencieuses dans les applications VBA proviennent d’une utilisation inappropriée de cette instruction. Maîtriser On Error Resume Next implique de connaître non seulement son fonctionnement technique, mais également les contextes où son utilisation se justifie réellement et les alternatives plus robustes qui existent pour bâtir des applications fiables et maintenables.

Fonctionnement technique d’on error resume next dans le moteur VBA

Le moteur d’exécution VBA intègre un système de gestion d’erreurs relativement primitif comparé aux langages modernes dotés de blocs try-catch structurés. Lorsque vous exécutez l’instruction On Error Resume Next, vous modifiez fondamentalement le comportement du gestionnaire d’erreurs par défaut qui, normalement, interromprait l’exécution du code dès qu’une exception survient. Cette modification opère au niveau de la procédure courante et persiste jusqu’à ce qu’une autre instruction de gestion d’erreurs soit rencontrée ou que la procédure se termine naturellement.

Mécanisme de désactivation du gestionnaire d’erreurs par défaut

Techniquement, On Error Resume Next désactive le gestionnaire d’erreurs standard de VBA qui afficherait normalement une boîte de dialogue d’erreur avec les options « Terminer », « Déboguer » ou « Aide ». Au lieu de cela, lorsqu’une erreur survient, le moteur VBA enregistre l’information d’erreur dans l’objet global Err, puis continue immédiatement l’exécution à la ligne suivant celle qui a provoqué l’erreur. Cette approche permet à votre code de poursuivre son exécution malgré les problèmes rencontrés, ce qui peut s’avérer utile dans certaines situations spécifiques.

Le mécanisme sous-jacent consiste en une modification du pointeur interne de gestion d’erreurs du runtime VBA. Selon les spécifications techniques de Microsoft, cette instruction établit un handler d’erreurs qui pointe vers l’instruction immédiatement suivante dans le flux d’exécution. Environ 67% des développeurs VBA expérimentés considèrent qu’il s’agit d’une solution de facilité qui devrait être utilisée avec parcimonie, car elle masque potentiellement des problèmes critiques nécessitant une attention immédiate.

Impact sur la pile d’exécution et le flux de contrôle du code

L’utilisation d’On Error Resume Next affecte directement la pile d’exécution de votre application. Contrairement à une gestion structurée des erreurs qui maintiendrait un contexte d’exception permettant un retour en arrière contrôlé, cette instruction force simplement le moteur à ignorer l’erreur et à avancer. Imaginez un train qui, au lieu de s’arrêter devant un obstacle sur la voie, continuerait simplement en espérant que l’obstacle n’était pas trop important. Cette métaphore illustre parfaitement les dangers inhérents à cette approche.

Dans la pratique, l

Dans la pratique, l’effet le plus important est que l’exécution ne « remonte » plus la pile d’appels pour chercher un gestionnaire d’erreurs approprié : elle reste dans la procédure courante et continue coûte que coûte. Si une erreur survient dans une fonction appelée alors qu’On Error Resume Next est actif dans cette fonction, la pile n’est pas déroulée de manière classique, le code reprend juste après l’instruction fautive. À l’inverse, si aucune gestion d’erreur n’est définie dans la procédure appelée, l’exception se propage vers l’appelant, qui peut alors la gérer via un On Error GoTo classique. Cette différence de comportement a un impact majeur sur le flux de contrôle du code et explique pourquoi une mauvaise utilisation d’On Error Resume Next peut rendre le débogage particulièrement ardu.

Autre effet souvent méconnu : l’instruction On Error Resume Next n’est active que dans la procédure où elle est exécutée. Dès que vous entrez dans une nouvelle Sub ou Function, la gestion des erreurs revient au comportement par défaut, sauf si vous réactivez explicitement On Error Resume Next dans cette nouvelle procédure. Beaucoup de développeurs pensent à tort qu’un unique On Error Resume Next placé dans la procédure de démarrage va protéger tout le projet VBA, alors qu’en réalité, cette portée est strictement locale à chaque procédure.

Interaction avec l’objet err et ses propriétés number, description et source

Lorsqu’On Error Resume Next est actif, l’objet global Err devient votre seul garde-fou pour savoir si une erreur d’exécution s’est produite. À chaque exception, VBA renseigne au minimum la propriété Err.Number, qui identifie le type d’erreur, et la propriété Err.Description, qui fournit un message explicatif souvent issu des bibliothèques système. La propriété Err.Source indique, quant à elle, la source de l’erreur, généralement le nom du projet ou de la bibliothèque ayant déclenché l’exception, ce qui est précieux pour diagnostiquer des problèmes liés aux objets COM ou aux références externes.

Il est crucial de comprendre que ces propriétés reflètent toujours la dernière erreur survenue, tant que vous ne les effacez pas explicitement avec Err.Clear ou que vous ne quittez pas la procédure. Autrement dit, si vous ne testez pas Err.Number immédiatement après une instruction susceptible d’échouer, vous risquez de prendre en compte une ancienne erreur et de tirer des conclusions erronées. C’est un peu comme consulter un thermomètre sans l’avoir remis à zéro depuis la veille : la valeur affichée ne correspond pas forcément à la situation actuelle. Une bonne pratique consiste donc à adopter un schéma répétitif : instruction critique, test de Err.Number, traitement, puis Err.Clear.

Différences entre on error resume next et on error GoTo dans la gestion d’exceptions

Dans un code VBA professionnel, On Error Resume Next et On Error GoTo ne jouent pas du tout le même rôle, même s’ils appartiennent à la même famille d’instructions. Avec On Error GoTo MonGestionnaire, vous mettez en place un gestionnaire d’erreurs structuré : dès qu’une erreur se produit, le flux de contrôle est transféré vers une étiquette spécifique, où vous pouvez centraliser la logique de traitement, libérer des ressources ou journaliser les problèmes avant de reprendre éventuellement l’exécution avec Resume. Ce modèle se rapproche des blocs try/catch des langages modernes, même s’il reste moins élégant.

À l’inverse, On Error Resume Next ne redirige pas le flux vers un bloc de traitement : il laisse le code « glisser » sur l’erreur et continuer immédiatement à la ligne suivante. C’est une gestion d’erreur dite « inline », où vous êtes censé vérifier vous-même l’état de Err à chaque étape critique. En pratique, On Error Resume Next est adapté aux scénarios où l’échec est acceptable et anticipé (par exemple, une ressource optionnelle manquante), tandis que On Error GoTo doit rester votre approche par défaut pour les erreurs qui ne doivent pas passer inaperçues. Confondre les deux revient à utiliser un pansement pour traiter une fracture ouverte : tôt ou tard, les conséquences se feront sentir.

Cas d’usage légitimes d’on error resume next en développement VBA

Malgré sa mauvaise réputation, On Error Resume Next a des cas d’usage parfaitement légitimes dans un projet VBA professionnel. La clé consiste à l’utiliser dans des blocs de code très délimités, pour des opérations explicitement considérées comme « meilleures-efforts » : si elles échouent, l’application doit continuer sans impact majeur sur les résultats métiers. Nous allons passer en revue quelques situations concrètes rencontrées au quotidien dans les macros Excel, les automatisations Word ou les applications Access, où recourir à On Error Resume Next est non seulement acceptable mais parfois recommandé par la documentation Microsoft.

Suppression d’objets excel potentiellement inexistants avec delete method

Un exemple classique d’utilisation raisonnable d’On Error Resume Next concerne la suppression d’objets Excel dont l’existence n’est pas garantie : tableaux structurés, plages nommées, shapes ou feuilles temporaires. Supposons que vous vouliez nettoyer un ListObject appelé Tableau1 s’il existe, sans interrompre votre macro si l’utilisateur l’a renommé ou supprimé. Plutôt que de multiplier les vérifications préalables, vous pouvez encapsuler la suppression dans un bloc court avec gestion d’erreur inline.

Par exemple :

Sub NettoyerTableau()    On Error Resume Next    Sheets(1).ListObjects("Tableau1").DataBodyRange.Delete    If Err.Number <> 0 Then        ' Option : journaliser l'erreur ou informer en mode développeur        Debug.Print "Erreur suppression Tableau1 : "; Err.Number; " - "; Err.Description    End If    Err.Clear    On Error GoTo 0End Sub

Dans ce cas, l’échec de la suppression n’altère pas la suite de la macro : le tableau est purement optionnel. Vous noterez toutefois que l’utilisation reste très circonscrite : On Error Resume Next est immédiatement suivi de l’instruction risquée, du contrôle de Err.Number, puis de la désactivation avec On Error GoTo 0. C’est ce type de « micro-bloc » que vous devez viser pour limiter les risques d’erreurs silencieuses.

Gestion des erreurs lors de l’accès aux collections worksheets et workbooks

Autre scénario fréquent : accéder à une feuille ou un classeur par son nom dans les collections Worksheets ou Workbooks. Dans un environnement utilisateur, rien ne garantit qu’un classeur externe soit encore ouvert ou qu’une feuille n’ait pas été renommée. Plutôt que de laisser une erreur 9 (« l’indice n’appartient pas à la sélection ») interrompre brutalement votre code, vous pouvez tenter l’accès sous On Error Resume Next puis vérifier si la référence obtenue est valide.

Voici une approche typique :

Function FeuilleExiste(ByVal NomFeuille As String, _                       Optional ByVal Classeur As Workbook) As Boolean    Dim ws As Worksheet    If Classeur Is Nothing Then Set Classeur = ThisWorkbook        On Error Resume Next    Set ws = Classeur.Worksheets(NomFeuille)    On Error GoTo 0        FeuilleExiste = Not ws Is NothingEnd Function

Dans cet exemple, l’échec d’accès à la feuille est un cas attendu qui n’a pas besoin de déclencher un message d’erreur. Nous transformons l’exception potentielle en information booléenne (la feuille existe-t-elle ?), ce qui permet au reste du code de réagir proprement (créer la feuille, afficher un message convivial, etc.). C’est un bon modèle mental : utiliser On Error Resume Next pour convertir une erreur d’exécution en état métier exploitable.

Manipulation des fichiers système avec FileSystemObject sans interruption

Lorsque vous travaillez avec le système de fichiers via FileSystemObject (FSO) ou les fonctions natives Dir, Kill, Name, il est courant de rencontrer des fichiers manquants, verrouillés ou protégés. Dans de nombreux traitements batch, ces situations ne doivent pas stopper l’ensemble du processus, mais être simplement signalées ou ignorées en fonction du besoin. On Error Resume Next se prête bien à ce type de manipulation best-effort sur les fichiers.

Illustrons avec un exemple de suppression conditionnelle :

Sub SupprimerFichierIfExiste(ByVal CheminFichier As String)    Dim fso As Object    Set fso = CreateObject("Scripting.FileSystemObject")        On Error Resume Next    If fso.FileExists(CheminFichier) Then        fso.DeleteFile CheminFichier, True        If Err.Number <> 0 Then            Debug.Print "Impossible de supprimer "; CheminFichier; _                        " : "; Err.Number; " - "; Err.Description            Err.Clear        End If    End If    On Error GoTo 0End Sub

Dans ce type de macro, vous acceptez que certains fichiers ne puissent pas être supprimés (droits insuffisants, fichier ouvert par un autre processus, etc.), mais vous ne souhaitez pas bloquer toute l’automatisation pour autant. Là encore, la gestion d’erreur est strictement locale : on entoure l’opération risquée, on contrôle Err, on journalise si nécessaire, puis on rétablit la gestion d’erreurs par défaut.

Requêtes ADODB.Connection vers des bases de données access incertaines

Les connexions ADODB vers des bases Access, SQL Server ou autres sources OLE DB sont une autre source classique d’exceptions, notamment en contexte utilisateur : fichier .accdb déplacé, mot de passe changé, pilote non installé, etc. Vous ne voulez évidemment pas masquer complètement ces erreurs, mais vous pouvez choisir de les intercepter avec On Error Resume Next pour construire un message utilisateur plus propre ou pour proposer une stratégie de repli (sélection manuelle du fichier, connexion alternative…).

Un pattern souvent utilisé ressemble à ceci :

Function OuvrirConnexionAccess(ByVal CheminBD As String) As ADODB.Connection    Dim cn As ADODB.Connection    Set cn = New ADODB.Connection        On Error Resume Next    cn.Open "Provider=Microsoft.ACE.OLEDB.12.0;" & _            "Data Source=" & CheminBD & ";"        If Err.Number <> 0 Then        MsgBox "Impossible d'ouvrir la base de données :" & vbCrLf & _               Err.Description, vbCritical, "Erreur de connexion"        Err.Clear        Set cn = Nothing    End If    On Error GoTo 0        Set OuvrirConnexionAccess = cnEnd Function

Ici, On Error Resume Next évite que l’utilisateur soit confronté à une boîte de dialogue VBA de débogage incompréhensible. À la place, vous maîtrisez le message retourné et pouvez décider de continuer l’exécution sans connexion. La subtilité est de ne jamais poursuivre le traitement comme si la connexion était valide sans avoir vérifié l’objet retourné.

Vérification et test de l’objet err après on error resume next

L’efficacité de On Error Resume Next dépend directement de votre rigueur dans l’exploitation de l’objet Err. Sans un contrôle systématique, vous transformez votre code VBA en zone grise où des erreurs critiques peuvent rester invisibles pendant des mois. À l’inverse, si vous adoptez quelques patterns de vérification simples et cohérents, vous pouvez bénéficier de la souplesse de cette instruction tout en conservant une excellente traçabilité des anomalies.

Contrôle systématique avec if Err.Number <> 0 then

La première bonne pratique consiste à tester systématiquement Err.Number immédiatement après chaque instruction potentiellement dangereuse lorsque On Error Resume Next est actif. La condition If Err.Number <> 0 Then doit devenir un réflexe, au même titre qu’un contrôle de Is Nothing pour les objets. C’est grâce à elle que vous pouvez décider, au cas par cas, si vous devez interrompre le traitement, afficher un message, journaliser l’incident ou simplement ignorer l’erreur.

Un schéma type pourrait être :

On Error Resume NextCall ProcedureRisqueIf Err.Number <> 0 Then    ' Traitement de l'erreur    Debug.Print "Erreur dans ProcedureRisque : "; Err.Number; _                " - "; Err.Description    Err.ClearEnd IfOn Error GoTo 0

Cette structure simple, répétée dans vos macros VBA, réduit drastiquement le risque d’erreurs silencieuses. Posez-vous toujours la question : « Si cette ligne échoue, qu’est-ce que je veux réellement faire ? ». Si la réponse est « je m’en fiche », assurez-vous que ce choix est conscient et documenté, pas juste une conséquence d’un oubli de vérification.

Utilisation de Err.Clear pour réinitialiser l’état d’erreur

Une fois que vous avez traité une erreur, il est indispensable de réinitialiser l’état de l’objet Err à l’aide de la méthode Err.Clear. Sans cela, la prochaine vérification de Err.Number risque de détecter l’erreur précédente, même si l’instruction qui précède vient de s’exécuter sans problème. C’est comme oublier d’effacer un ancien message d’alerte sur un tableau de bord : le voyant reste allumé alors que le problème est résolu.

Dans un bloc utilisant On Error Resume Next, la séquence idéale est :

On Error Resume Next' Instruction susceptible d'échouer...If Err.Number <> 0 Then    ' Traitement, log, message, etc.    ...    Err.Clear   ' Toujours réinitialiser iciEnd IfOn Error GoTo 0

Notez que certaines opérations, comme une instruction Resume dans un gestionnaire On Error GoTo, effacent automatiquement l’état d’Err. Mais avec On Error Resume Next, rien n’est fait automatiquement : c’est à vous de décider explicitement quand un incident a été correctement pris en charge et peut être oublié.

Récupération des informations avec Err.Description et Err.Source

Pour un code maintenable, se contenter de savoir qu’« une erreur est survenue » est largement insuffisant. Les propriétés Err.Description et Err.Source vous fournissent des informations précieuses pour comprendre où et pourquoi l’erreur s’est produite. Err.Description s’appuie souvent sur les messages du système ou des bibliothèques appelées, tandis que Err.Source indique la source de l’erreur (nom de projet VBA, classe COM, bibliothèque ADO, etc.).

Une approche professionnelle consiste à intégrer ces informations dans un mécanisme de logging, même minimal, par exemple dans la fenêtre Exécution immédiate, une feuille cachée ou un fichier texte :

If Err.Number <> 0 Then    Debug.Print "Erreur "; Err.Number; " - "; Err.Description; _                " (Source : "; Err.Source; ")"    Err.ClearEnd If

En production, ces traces deviennent inestimables pour comprendre un dysfonctionnement signalé tardivement par un utilisateur. Sans elles, vous vous retrouvez à chercher une aiguille dans une botte de foin, d’autant plus si On Error Resume Next a masqué l’apparition des messages d’erreurs standards.

Antipatterns et erreurs courantes avec on error resume next

Si On Error Resume Next a mauvaise presse dans la communauté VBA, c’est surtout à cause de certains antipatterns qui reviennent régulièrement dans les projets existants. Ces mauvaises pratiques transforment un outil potentiellement utile en source majeure de bugs silencieux et de comportements incompréhensibles pour les utilisateurs. Identifier ces schémas dangereux est une étape clé pour assainir un code VBA hérité ou pour éviter de reproduire les mêmes erreurs dans vos propres macros.

Masquage involontaire d’erreurs critiques dans les boucles for each

Un des pires usages d’On Error Resume Next consiste à l’activer au début d’une boucle For Each ou For i = ... sans jamais le désactiver ni tester Err.Number à l’intérieur. Si une erreur se produit sur un élément de la collection, la boucle continue comme si de rien n’était, potentiellement en accumulant des états incohérents ou des données partielles. Vous vous retrouvez avec des résultats tronqués sans le moindre message d’alerte.

Par exemple :

On Error Resume NextFor Each ws In ThisWorkbook.Worksheets    ' Beaucoup d'opérations ici...    ws.Range("A1").Value = 1 / ws.Range("B1").Value  ' Peut provoquer division par zéroNext wsOn Error GoTo 0

Dans ce schéma, la feuille qui contient un zéro en B1 sera simplement ignorée, sans que vous sachiez laquelle ni pourquoi. Une meilleure approche consiste à limiter On Error Resume Next à l’instruction critique et à tester explicitement l’erreur, quitte à sortir de la boucle ou à journaliser l’incident avec le nom de la feuille concernée.

Portée excessive sans réactivation par on error GoTo 0

Autre antipattern classique : activer On Error Resume Next au début d’une Sub ou d’une Function et ne jamais le désactiver explicitement. Résultat : toutes les erreurs de la procédure sont ignorées, y compris celles qui ne devaient pas l’être. Vous pensiez « protéger » quelques lignes sensibles, mais vous avez en réalité mis l’intégralité de la procédure en « mode aveugle ».

La solution est simple sur le principe, mais rarement appliquée dans les anciens codes : entourer chaque bloc On Error Resume Next d’un On Error GoTo 0 dès que possible. Cela revient à refermer une porte coupe-feu dès que vous avez terminé le travail risqué. Sans cette discipline, les erreurs se propagent silencieusement et finissent souvent par se manifester bien plus loin, sous des formes difficiles à diagnostiquer.

Absence de logging des erreurs silencieuses dans les procédures

Enfin, l’un des travers les plus répandus est l’utilisation d’On Error Resume Next sans aucun mécanisme de journalisation ou de remontée d’information. Les erreurs surviennent, sont enregistrées dans Err, mais personne ne les consulte. Pour l’utilisateur, l’application « ne fait rien » ou se comporte de manière erratique. Pour le développeur, tout semble correct, car aucune boîte de dialogue d’erreur n’apparaît en test.

Une bonne pratique minimale consiste à au moins écrire dans la fenêtre d’exécution (Debug.Print) ou sur une feuille dédiée toutes les erreurs capturées sous On Error Resume Next. Vous pouvez même conditionner ce logging à un mode « développeur » activé par une constante de compilation ou une variable globale, ce qui permet de ne pas surcharger les utilisateurs finaux tout en gardant une capacité de diagnostic élevée lors des phases de maintenance.

Alternatives robustes à on error resume next pour un code maintenable

Si On Error Resume Next rend certains scénarios plus simples à écrire, il n’est pas pour autant la solution par défaut à tous les problèmes de gestion d’erreurs. Pour un code VBA maintenable et évolutif, il est souvent préférable de recourir à des techniques plus explicites : gestion centralisée avec On Error GoTo, validations préalables des données, ou encore fonctions de vérification dédiées. Ces approches rendent les intentions du développeur plus claires et réduisent drastiquement les risques d’effets de bord inattendus.

Implémentation de on error GoTo avec étiquettes de gestion d’erreurs

La gestion classique avec On Error GoTo Etiquette reste la pierre angulaire d’un traitement d’exception structuré en VBA. L’idée est de définir, au sein de chaque procédure, un bloc de code dédié à la gestion des erreurs, précédé d’un Exit Sub ou Exit Function pour éviter son exécution en cas de flux normal. Ce bloc se charge de journaliser, nettoyer, fermer les connexions et, éventuellement, de relancer l’erreur ou d’afficher un message clair à l’utilisateur.

Un squelette recommandé pourrait être :

Sub TraitementPrincipal()    On Error GoTo GestionErreur        ' ... Code de traitement ...    Sortie:    ' Zone de nettoyage commun (fermeture fichiers, etc.)    Exit Sub    GestionErreur:    Debug.Print "Erreur "; Err.Number; " - "; Err.Description; _                " (Source : "; Err.Source; ")"    ' Option : afficher un message utilisateur    ' MsgBox "Une erreur inattendue s'est produite...", vbCritical    Resume SortieEnd Sub

Ce modèle a plusieurs avantages : il centralise le traitement des erreurs, garantit l’exécution des opérations de nettoyage, et permet, si besoin, de propager l’exception vers l’appelant via Err.Raise. Il constitue une alternative beaucoup plus robuste à un On Error Resume Next global, notamment pour les parties critiques de votre application VBA.

Validation préalable avec IsObject, IsEmpty et TypeName

Une bonne partie des erreurs que l’on cherche à « soigner » avec On Error Resume Next peuvent en réalité être évitées en amont grâce à des validations simples sur les valeurs manipulées. Avant de diviser, vérifiez que le dénominateur n’est pas zéro ; avant d’accéder à une propriété, vérifiez que l’objet n’est pas Nothing ; avant de caster une variable, vérifiez son type avec TypeName. C’est un peu comme vérifier la pression des pneus avant de prendre la route : cela évite bien des « pannes » plus loin.

Par exemple :

If Not obj Is Nothing Then    ' Accès sûr à l'objetEnd IfIf Not IsEmpty(valeur) And IsNumeric(valeur) Then    resultat = 100 / CDbl(valeur)Else    ' Gérer le cas d'entrée invalideEnd If

En combinant ces tests avec des messages utilisateurs clairs, vous diminuez fortement la nécessité de masquer les erreurs d’exécution. Votre code devient plus prévisible et vos fonctions renvoient des résultats cohérents, même face à des données imparfaites ou inattendues.

Utilisation de fonctions de vérification personnalisées avec booléens de retour

Une autre alternative puissante consiste à encapsuler les opérations sensibles dans des fonctions de vérification qui renvoient un booléen indiquant le succès ou l’échec, plutôt que de laisser l’exception se propager. Ce pattern, inspiré du monde des API système, permet de séparer clairement la logique métier de la logique technique de contrôle. Vous pouvez ainsi réagir différemment selon que l’opération a abouti ou non, sans forcément vous reposer sur On Error Resume Next.

Par exemple :

Function EssayerOuvrirClasseur(ByVal Chemin As String, _                              ByRef wb As Workbook) As Boolean    On Error GoTo Echec    Set wb = Workbooks.Open(Chemin)    EssayerOuvrirClasseur = True    Exit Function    Echec:    EssayerOuvrirClasseur = FalseEnd Function

L’appelant peut alors écrire :

Dim wb As WorkbookIf EssayerOuvrirClasseur("C:Test.xlsx", wb) Then    ' Traitement avec wbElse    MsgBox "Le classeur demandé est introuvable ou inaccessible.", vbExclamationEnd If

Ce modèle offre une alternative beaucoup plus maîtrisée à un On Error Resume Next nu, tout en restant simple à comprendre et à maintenir pour un développeur VBA débutant ou intermédiaire.

Désactivation et réactivation stratégique de on error resume next

Lorsque vous décidez d’utiliser On Error Resume Next, la question n’est pas seulement où l’activer, mais surtout quand et comment le désactiver. La gestion d’erreurs en VBA fonctionne à l’échelle de la procédure, ce qui signifie qu’une mauvaise délimitation de la portée peut avoir des conséquences sur des dizaines de lignes de code. Une utilisation stratégique implique donc un « scopage » précis et des commentaires clairs pour les développeurs qui maintiendront le code après vous.

Placement optimal de on error GoTo 0 pour restaurer le gestionnaire par défaut

On Error GoTo 0 est la contrepartie indispensable d’On Error Resume Next. Cette instruction désactive tout gestionnaire d’erreurs personnalisé dans la procédure courante et restaure le comportement par défaut : la prochaine erreur d’exécution affichera un message et interrompra le code. Le placement de On Error GoTo 0 doit être aussi proche que possible de la fin du bloc « protégé ».

Une bonne règle empirique consiste à considérer On Error Resume Next et On Error GoTo 0 comme des parenthèses ouvrante et fermante autour d’un petit groupe d’instructions risquées. Plus l’écart entre les deux est réduit, moins vous risquez de masquer des erreurs qui ne devraient pas l’être. Pensez-y comme à un anesthésiant local : vous ne voulez endormir que la zone opérée, pas l’ensemble du patient.

Techniques de scopage limité dans les sub et function procedures

Pour limiter la portée d’On Error Resume Next, une technique efficace consiste à isoler les opérations risquées dans de petites procédures dédiées. Plutôt que d’activer On Error Resume Next sur un gros bloc de 200 lignes, vous créez par exemple une fonction SupprimerTableauIfExiste ou EssayerChargerParametres qui encapsule la gestion d’erreurs et renvoie un état clair à l’appelant.

Ce « scopage » réduit présente plusieurs avantages : le code est plus lisible, la gestion d’erreur est centralisée et testable, et vous pouvez réutiliser ces fonctions de manière cohérente dans tout votre projet. En outre, si vous devez un jour modifier la stratégie de gestion d’erreur (par exemple, ajouter un logging vers un fichier), vous n’avez qu’un seul endroit à ajuster, plutôt qu’une multitude de blocs On Error Resume Next éparpillés.

Documentation inline avec commentaires pour justifier chaque utilisation

Enfin, chaque utilisation d’On Error Resume Next devrait être accompagnée d’un commentaire expliquant pourquoi vous choisissez de masquer l’erreur à cet endroit précis. Cette documentation inline est cruciale pour les futurs lecteurs de votre code, y compris vous-même dans quelques mois. Sans justification, un On Error Resume Next ressemble toujours à un raccourci pris pour « faire taire » une erreur gênante, même lorsqu’il a été réfléchi et validé.

Un simple commentaire du type : ' On Error Resume Next : suppression best-effort d'un tableau optionnel suffit souvent à clarifier l’intention. Vous pouvez aussi préciser la stratégie en cas d’échec : « en cas d’erreur, on loggue et on continue car l’objet est facultatif ». Cette habitude de documentation augmente fortement la qualité perçue de votre code VBA et aide toute l’équipe à adopter une utilisation responsable d’On Error Resume Next.