Détection d'erreur

Mercredi à 14:07

Bonjour,

J'ai crée un programme qui fonctionne au vu du cahier des charges. Il y a juste un problème que j'ai identifié dans la gestion d'erreur. Voici deux extraits du code VBA :

Call Flag
    If Flag_Error = False Then
        Call CopyDataFromIFileToOFile
        Call CreationDataOSheet
        Call Initialization
        Call Decision
        Call Acts
        Call Total
        Call ActsCasings
        Call GraphicsDecisions
        Call GraphicsActsObjects
        Workbooks(Inputfilename).Close
        Workbooks(Outputfilename).SaveAs pathOF
        Workbooks(Outputfilename).Close
    Else
        Exit Sub
    End If

Flag est la procédure dans laquelle se trouve la vérification de l'absence d'erreurs. Flag_Error est un drapeau changeant d'état (1 ou 0) selon qu'une erreur est détectée ou pas.

Dans la procédure Flag, il y a ceci entre autres :

Workbooks.Open (pathIF)
Set Check_Name = Workbooks(Inputfilename).Worksheets(InputSheetName)
If Check_Name Is Nothing Then
    MsgBox "La feuille du classeur d'entrée n'existe pas.", vbCritical, InputSheetName
    Flag_Error = True
    Workbooks(Inputfilename).Close
    Exit Sub
Else
    Flag_Error = False
End If

Si j'exécute l'appli. et que je saisie une donnée sans une erreur glissée volontairement, alors il n'y a pas de message. Ce qui est normal. Ca marche bien.

Si j'exécute l'appli. et que je saisie une donnée avec une erreur glissée volontairement, alors le message censé apparaître (voir ci-dessus) n'apparaît pas. A la place, c'est un message de VBA : Erreur d'exécution 9 : l'indice n'appartient pas à la sélection.

Si j'exécute l'appli. une troisième fois et que je saisie une donnée avec une erreur glissée volontairement (la même par exemple), alors le message censé apparaître apparaît. Ca marche bien.

Je ne comprends pas ce comportement. Dans les 1èr et 3ème cas, la procédure est parcourue et l'erreur spécifique est détectée. C'est comme si dans le 2ème cas, elle ne l'était pas car dans le blocage il indique que Flag_Error=False, ce qui est faux puisqu'il y a erreur.

Mercredi à 17:04

Bonjour,

Ce n'est pas facile de vous donner une réponse adéquate sans voir le fichier où le code complet et la déclaration des variables

je me pose ces questions :
- votre déclaration de variable Dim Flag_Error est placée où ?
- le code s'arrête sur quelle ligne lorsque vous avez l'erreur

Mercredi à 21:23

Bonsoir,

vous avez également la touche [F8] pour suivre ce que fait VBA pas à pas...

Et pourquoi créer une procédure de gestion d'erreur alors que VBA le fait très bien ?

Sub Test()
    Workbooks.Open (pathIF)
    On Error GoTo SheetName
        Set Check_Name = Workbooks(Inputfilename).Worksheets(InputSheetName)
    On Error Resume Next
    ' le code ci dessous ne tournera que s'il n'y a pas d'erreur sur le nom de la feuille
    ' on peut ajouter une deuxième gestion d'erreur
    On Error GoTo SuitePRG
        Call CopyDataFromIFileToOFile
        Call CreationDataOSheet
        Call Initialization
        Call Decision
        Call Acts
        Call Total
        Call ActsCasings
        Call GraphicsDecisions
        Call GraphicsActsObjects
        Workbooks(Inputfilename).Close
        Workbooks(Outputfilename).SaveAs pathOF
        Workbooks(Outputfilename).Close
    On Error Resume Next
    ' tout c'est bien passé, on quitte la sub
    Exit Sub

SheetName:
    MsgBox "La feuille du classeur d'entrée n'existe pas.", vbCritical, InputSheetName
    Exit Sub

SuiteRPG:
    MsgBox "Une erreur s'est produite dans la ""suite"" du programme.", vbCritical
    Exit Sub
End Sub

A voir...

@ bientôt

LouReeD

Hier à 15:53

Bonjour à vous,

Merci tous les 2 !

J'ai ajouté une couche de prévention d'erreur avec la structure :

On Error GoTo Verif
        [...]
On Error Resume Next
    ' tout c'est bien passé, on quitte la sub
    Exit Sub

SuiteVerif:
    MsgBox "Une erreur s'est produite dans la ""suite"" du programme.", vbCritical
    Exit Sub
End Sub

A priori, ça fonctionne. J'ai fait plusieurs tests d'affilée. Pas d'anomalie relevée. Je retenterai de le faire fonctionner chez moi. Je verrais si je reprends toute la gestion d'erreur ou si je laisse cette couche supplémentaire venant se superposer aux autres. Pour l'instant, je ne suis pas encore arrivé à trouver la cause du problème.

Hier à 17:39

re

J'ai ajouté une couche de prévention d'erreur avec la structure :

ok si cela fonctionne mais ceci m'interpelle :

On Error Resume Next
    ' tout c'est bien passé, on quitte la sub
    Exit Sub

A priori, le On error resume next ne sert pas à cet endroit puisque la ligne suivante vous sortez du code via l'instruction Exit Sub

Après au début du code cela devrait être ceci il me semble 

On Error GoTo SuiteVerif

Si ok pensez à fermer le fil.

Cordialement

Hier à 17:57

Bonjour,

Pour l'instant, je ne suis pas encore arrivé à trouver la cause du problème.

lorsqu'une macro essaie d'accéder (faire référence) à une feuille qui n'existe pas, vba interrompt la macro avec une message d'erreur (erreur 9 dans ce cas). Pour gérer les erreurs, il faut utiliser l'instruction on error. Ce que tu retrouves dans les solutions proposées.

Hier à 17:57

Pour activer la gestion personnalisée des erreurs en VBA, plusieurs instructions peuvent être utilisées :

  • On Error Resume Next
    En cas d’erreur, VBA ignore l’erreur et poursuit l’exécution à l’instruction suivante.
  • On Error GoTo NomEtiquette
    En cas d’erreur, VBA interrompt l’exécution normale et se dirige vers l’étiquette indiquée.
    À cet endroit, on place les instructions de traitement de l’erreur.
    Le traitement se termine généralement par une instruction Resume :
    • Resume : reprend l’exécution à l’instruction qui a provoqué l’erreur.
    • Resume Next : reprend à l’instruction située juste après celle qui a provoqué l’erreur.
    • Resume NomEtiquette : reprend l’exécution à l’étiquette indiquée.

Pour désactiver la gestion des erreurs :

  • On Error GoTo 0
    Désactive la gestion d’erreur personnalisée et rétablit le comportement normal de VBA.
Aujourd'hui à 08:56

Bonjour,

Merci pour votre retour et remerciement !

@Dan : si le on error resume next vous interpelle alors vous devez l'être régulièrement en lisant les questions réponses... ça ne sert a rien mais comme screenupdating c'est plus "joli" d'encapsuler le code entre l'arrêt et la remise en route surtout s'il y a des appels de procédure en cascade. Ici au vu du manque de code, on ne sait pas d'où l'on vient et on ne sait pas trop où l'on va. Dans le doute maîtrise total de la gestion d'erreur, non ?

@ bientôt

LouReeD

Aujourd'hui à 09:10

@LooReed

si le on error resume next vous interpelle alors vous devez l'être régulièrement en lisant les questions réponses...

Qu'est ce qui vous dit que je ne les lis pas...
Mon post n'était pas un reproche mais juste une pensée. Désolé.

Ici au vu du manque de code, on ne sait pas d'où l'on vient et on ne sait pas trop où l'on va.

Exact

Aujourd'hui à 09:21

Je ne dis pas que vous ne les lisez pas, je dis juste tout comme moi, si je puis me permettre, vous devez voir voir ces "lignes" qui ne servent pas et qui vous hérissent les poils ! Un peu comme pour ceci :

With ActiveCell
    .Value = "LouReeD"
End With

Le With permet de simplifier le code, mais si ce n'est que pour une instruction alors ce n'est pas nécessaire, comme pour :

Dim Cel As Range
Set Cel = ActiveSheet.Range("A1")
'.....
Cel.Value = "LouReeD"
'....

Si Cel ne sert qu'une fois, inutile de la mettre en mémoire... Me semble-t-il, non ?

J'ai arrêté de le signaler, car au fond avec l'indentation du code, cela permet d'encapsuler les lignes concernées par les instructions...

Passez un bon weekend !

@ bientôt

LouReeD

Aujourd'hui à 09:49

@LouReeD,

j'ai appris quelque chose aujourd'hui, , votre code de mercredi ... . On met un "On error goto ..." puis on fait plusieurs "calls" vers des autres macro, puis un nouveau "On error goto ..." vers un autre handler, et des nouveaux "Calls", etc. Apparament, on peut faire des erreurs dans un de vos "calls" (ou procedures en cascade), ça saut vers l'adresse du dernier "Goto". Je ne savais pas que cela fonctionnait comme-ca et je ne suis pas sûr que cela me rend heureux ou triste. Dans les rares cas que j'utilise ce "on error", ce n'est que pour quelque lignes (disons max 10, avec des exceptions).

Donc, mon poste est un peu dans la zone grise. Ce "on erreur" sauve la macro parce qu'ainsi elle ne s'arrête pas en erreur mais on ne connait pas la raison sauf avec (cfr ici dessous) mais on ne sait pas dans quel "call" et cela est ambetent.

Avec votre méthode, on ajoute une autre dimension d'experience à cet outil et je suppose que c'est très pratique pour les experts mais cela "hérissent les poils" des autres. Que pensez-vous ...

     ...
     On error goto Verif
     ....
     Exit Sub
Verif:
     MsgBox "Numéro de l'erreur " & Err.Number & vbLf & Err.Description, vbCritical, "on a eu une erreur"
End Sub
Aujourd'hui à 10:19

@LooReed

Le With permet de simplifier le code, mais si ce n'est que pour une instruction alors ce n'est pas nécessaire
.....
Si Cel ne sert qu'une fois, inutile de la mettre en mémoire... Me semble-t-il, non ?

Parfaitement !
Quelques fois ce sont des résidus de modifications des codes que l'on laisse en l'état au lieu de corriger. Et pour celui qui intervient, on se pose la question du pourquoi et cela rend la lecture moins facile ou plus longue inutilement.

Merci et passez également un bon WE !

@Bsalv

Donc, mon poste est un peu dans la zone grise. Ce "on erreur" sauve la macro parce qu'ainsi elle ne s'arrête pas en erreur mais on ne connait pas la raison sauf avec (cfr ici dessous) mais on ne sait pas dans quel "call" et cela est ambetent.

Exactement. De mon coté je suggère toujours plusieurs petites macros plutôt qu'une longue. Surtout avec VBA car on arrive trop vite à une "usine à gaz"

Bon WE !

Crdlt

Aujourd'hui à 11:05

BsAlv,

Le code de mercredi était de permettre au demandeur de gérer l'erreur d'une feuille absente du classeur, et ne pas laisser VBA s'en charger avec l'indice n'appartient pas à la sélection... comme cela l'utilisateur sait que c'est un problème de feuille.

Je suis resté sur sa "structure" de code pour la forme, et le fait de mettre une deuxième étiquette cela permet de différencier l'erreur en fonction de la partie du code affecté. Mais c'est loin d'être optimisé, mais avec le peu de données fournies cela me semble suffisant après tout.

Pour la mise en place d'une bonne gestion des erreurs il faudrait voir l'application dans son ensemble.

Et pour ce qui est des quelques lignes c'est ce que je dis avec l'encapsulage du code.

Merci de bien vouloir sortir de la zone grise, c'est un bon week-end (ensoleillé) qui s'annonce.

@ bientôt

LouReeD

Rechercher des sujets similaires à "detection erreur"