On Error Go dans une boucle

Signaler
Messages postés
37
Date d'inscription
jeudi 28 septembre 2006
Statut
Membre
Dernière intervention
18 juin 2007
-
Messages postés
1
Date d'inscription
dimanche 16 octobre 2005
Statut
Membre
Dernière intervention
2 février 2008
-
Hello boyz

Mon instruction "On error Go To", prévue pour l'erreur d'une " selection.Find(what:=.......)
ne marche qu'une fois.

Elle est à l'intérieur d'une boucle For NExt. 
Le On Error est placé juste avant la recherche, et ça ne marche que pour la première erreur rencontrée, dès que la bouvle a fait un tour, le Goto ne marche plus.
 
ca vous dis qqch?

20 réponses

Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
36
Une fois la première erreur rencontrée, l'execution du code est passée au gestionnaire d'erreur et celui-ci est désactivé jusqu'a la fin de la gestion de l'erreur (généralement automatique à la sortie de la procédure). Pendant ce temps là, les erreurs ne sont plus gérées

Si après une première erreur, tu continue l'execution de ton code normal, cette execution sera considérée comme étant le traitement de l'erreur.

Donc après avoir traiter l'erreur, pour pouvoir continuer à executer le code normalement sans sortir de la procédure, il faut passer à terminer la gestion d'erreur, pour relancer le gestionnaire.
--> Err.Clear

---- Sevyc64  (alias Casy) ---- # LE PARTAGE EST NOTRE FORCE #
Messages postés
182
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
14 mars 2011

ta mis "exit sub" avant la gestion de ton exeption?
on error MY_EXCEPTION

instruction
exit sub
MY_EXCEPTION :
traitement de l'exeption
end sub
montre nous ton code pour plus de precision
Messages postés
37
Date d'inscription
jeudi 28 septembre 2006
Statut
Membre
Dernière intervention
18 juin 2007

L'instruction "Err.Clear" est à mon avis ce qui réponds à ma question. Merci bien
Mais je n'arrive pas pas à la faire marcher :
J'ai essayer de placer le err.clear au début de la boucle, a la fin, juste après l'instruction de Goto (ici c'etait Goto copie, donc juste après le Goto...)

Et voila le code pour kazer

 For i = 2 To NbLIgnes
  Err.Clear
 If Cells(i, 3) Like "*Somme*" Then
 Cells(i + 1, 2).Select
   
    isin = ActiveCell
    Windows("POS T0.xls").Activate
    Range("B:B").Select
    [B2].Activate
   
    On Error GoTo copie
    ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row()
    Rows(ligneisin).Copy
copie:
  
    Windows("MVT 1.xls").Activate
   
    Rows(i + 1).Select
    Selection.Insert shift:=xlDown
     Selection.End(xlToLeft).Select

(err.clear)

end if
next i
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
25
le Err clear ne sert ici rigoureusement à rien puisque, dans ta boucle For to tu repasses par un On Error (lequel, conformément à VB, réinitialise automatiquement err à 0

Voilà ce qu'explique VB :

"The Err object's properties are reset to zero or zero-length strings ("") after any form of the Resume or On Error statement and after an Exit Sub, Exit Function, or Exit Property statement within an error-handling routine. The Clear method can be used to explicitly reset Err".




Explique nous avec des mots simples ce que tu cherches exactement à faire (commente ton code tel que tu l'as écrit) et nous verrons ensemble quelle est la meilleure façon de s'y prendre.
Messages postés
6786
Date d'inscription
vendredi 16 décembre 2005
Statut
Membre
Dernière intervention
21 décembre 2011
18
Salut,

il faut gérer avec le numéro de l'erreur.

    On Error Resume Next

For i =  2 To NbLIgnes
    If Cells(i, 3) Like "*Somme*" Then
        Cells(i + 1, 2).Select
        isin = ActiveCell

        Windows("POS T0.xls").Activate

        Range("B:B").Select
        [B2].Activate
    
        If Not Err.Number = XXXXThen
'       remplace XXXX par le bon numéro d'erreur
            ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row()
            Rows(ligneisin).Copy
        End If

        Windows("MVT 1.xls").Activate
    
        Rows(i + 1).Select
        Selection.Insert shift:=xlDown
        Selection.End(xlToLeft).Select
    End If
Next i

On Error GoTo 0
~<small> Mortalino </small>~

@++

<hr width ="100%" size="2" />
  --Mortalino--
Le mystérieux chevalier, "Provençal, le Gaulois"
/DIV>
Messages postés
630
Date d'inscription
vendredi 5 mai 2006
Statut
Membre
Dernière intervention
17 février 2007

Heu ... Au risque de passer pour un empêcheur de tourner en rond, oserais-je dire que l'utilisation d'un "On error goto" en vba, vb6 (ou antérieur) ou d'un "Try ... Catch" en vb.2005 n'est qu'un pis-aller ? Et un inutile bouffeur de resources ?
Oserais-je affirmer que dans 99% des cas, il suffit d'être rigoureux dans le choix des variables, le contrôle des saisies, ... en fait dans la maîtrise de son propre prog ? Peut-être même que le 1% qui reste peut être maîtrisé aussi d'ailleurs.
Personnellement, dans mes progs, je contrôle toutes les entrées et sorties et n'ai jamais eu à utiliser les "on error" en vba ou vb6 ni les "try ... catch" en vb.2005 (sauf en phase de test par fainéantise).

A force de laisser la machine gérer les erreurs, on va finir par remplacer les programmeurs par des machines.
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
25
Et pourtant , cher Dolphin Boy, et pourtant !...
Le vieux développeur que je suis te dira que c'est quelquefois justifié, voire incontournable...
Un exemple ?
OK :
Décider de l'utilisation de la première police de caractères disponible sur un PC client parmi une liste de polices possibles, et dans un ordre préférentiel déterminé, sans faire une multitude de tests inutiles d'existence !
et j'en passe, et des meilleures
Messages postés
148
Date d'inscription
samedi 4 novembre 2006
Statut
Membre
Dernière intervention
4 décembre 2008

Dolphin Boy => Tu as surement raison mais la plupart des personnes qui débutent en vb utilisent ce genre de fonction pour connaitre les erreurs qu'il peuvent faire ou, comme tu le dis toi même, "en phase de test par fainéantise" . (sans rancune j'espere)
sinon err.description peut aussi faciliter la compréhension de l'erreur 

Quand je suis là tout va mal  
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
36
Je suis entièrement d'accord avec toi Dolphin, pour VB6, moins pour VB.NET.
Le try catch n'a absolument rien à voir avec le on error, c'est même pas comparable.

Cependant, et je suis le premier à ne pas le faire, toutes les routines devraient avoir un gestionnaire d'erreur, car même le code le plus abouti n'est pas à l'abris du bug imprévu. Aucun code ne pourra jamais etre zéro bug, c'est impossible.Et sans gestion de l'erreur, c'est la fermeture brutale de l'appli.
Et lorsque derrière tu as une machine, ça peut etre synonime de casse ou pire de mise en danger de personne.

D'accord avec jmfmarques aussi, parfois c'est incontournable.

---- Sevyc64  (alias Casy) ---- # LE PARTAGE EST NOTRE FORCE #
Messages postés
7668
Date d'inscription
samedi 5 novembre 2005
Statut
Membre
Dernière intervention
22 août 2014
25
Toujours pas d'accord ...
Un autre exemple, alors :
Tenter d'ouvrir (avec un Open) un fichier déjà ouvert par une autre application (avec un Open également) !
Messages postés
630
Date d'inscription
vendredi 5 mai 2006
Statut
Membre
Dernière intervention
17 février 2007

leSaleGauSS > sans rancune bien sùr. Et je suis OK avec toi. Mais le prog final (livré au client) doit, à mon avis (et idéalement ) être exempt de ce genre de chose sous peine de s'attendre à des bugs qu'on ne saura pas gérer puisqu'on n'aura déjà pas su géré les erreurs au départ.
jmfmarques > si tu utilises des polices non standard, qui t'empêche de les fournir avec ton pack d'install ? Ou de les indiquer comme pré-requis ?
Messages postés
630
Date d'inscription
vendredi 5 mai 2006
Statut
Membre
Dernière intervention
17 février 2007

casy > bien sùr, aucun prog n'est à l'abri d'un bug non prévu par le développeur. Je me suis sans doute mal exprimé. Ce que je voulais dire c'est qu'il ne faut pas utiliser la gestion d'erreur pour n'importe quoi sans réfléchir. 
Messages postés
148
Date d'inscription
samedi 4 novembre 2006
Statut
Membre
Dernière intervention
4 décembre 2008

Dites loin de moi l'idée de remuer le couteau dans la plaie, mais vous trouver pas (et la je m'adresse a Dolphin Boy et jmfmarques) qu'on s'eloigne un peu du sujet.
A moins qu'il a changer entre temps par "Pour ou contre le On error go to" ?
Mais si vous voulez continuer ya pas de probleme (C'est gregcitt qui va être content)

Quand je suis là tout va mal  
Messages postés
630
Date d'inscription
vendredi 5 mai 2006
Statut
Membre
Dernière intervention
17 février 2007

leSaleGauSS tu n'as pas tord mais <gregcitt> peut peut-être éviter ce "on error" ? Faudrait voir son code.
Messages postés
630
Date d'inscription
vendredi 5 mai 2006
Statut
Membre
Dernière intervention
17 février 2007

Oups, mea culpa. Vu le code vba. Suis trop nul en vba. Peut-être bien que dans ce langage on ne peut pas faire autrement.
Messages postés
6786
Date d'inscription
vendredi 16 décembre 2005
Statut
Membre
Dernière intervention
21 décembre 2011
18
Salut,

merci d'inonder ma boite mail avec ce sympathique débat
Beh du coup, on va pas venir pour rien :
je suis pour le fait de réduire au maximum l'utilisation de on error, mais qui dit réduire, dit utilisable pour certains cas (pas le choix, ou PAR choix).

Perso, je l'utilise comme le code proposé à gregcitt (d'ailleurs si ça te convient, n'hésite pas) dans certains cas, et pour mes chers doublons.
J'aime bien travailler avec les collections pour traiter les données, car si on tente d'ajouter un item avec une clé (le nom de l'item) et si la clé d'un membre est la même, cela provoque une erreur, car les collections n'acceptent que les clés uniques.

Du coup, on error resume next avant le traitement, on error goto 0 juste après, et ça m'évite 2 ou 3 boucles pour vérifier les données, et des ReDim intempestifs.

@++


  --Mortalino--
Le mystérieux chevalier, "Provençal, le Gaulois"
<!--
Messages postés
6786
Date d'inscription
vendredi 16 décembre 2005
Statut
Membre
Dernière intervention
21 décembre 2011
18
Sinon, si c'est bien le numéro de la ligne que tu recherches, revérifie ton code :

ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row<strike>()</strike>

C'est    .Row
Row() n'existe pas.

Donc dans tous les cas de figure, telle qu'est ton code avec ces (), la recherche ne n'effectuera pas car il y a une erreur de syntaxe.

Donc pour répondre à Dolphin Boy, oui on peut éviter la gestion d'erreur :
tout simplement, en écrivant BIEN, surtout que si la recherche est infructueuse, cela renvoi une chaine vide, et non une erreur.

For i = 2 To NbLIgnes
    If Cells(i, 3) Like "*Somme*" Then
        Cells(i + 1, 2).Select
        isin = ActiveCell

        Windows("POS T0.xls").Activate

        Range("B:B").Select
        Range("B2").Activate
   
        ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row
        Rows(ligneisin).Copy
  
        Windows("MVT
1.xls").Activate
   
        Rows(i + 1).Select
        Selection.Insert shift:=xlDown
        Selection.End(xlToLeft).Select
    End If
Next i

--Mortalino--

Pour Dolphin Boy, VBA n'est pas vraiment différent de VB, en tout cas la gestion d'erreur est exactement la même.
Seules les bibliothèques et objets diffèrent, et encore que..
Il faut se dire que VB, c'est une application pour en faire d'autre, VBA, c'est un complément d'une application hôte. Mais la hierarchisation des objets, classes sont les mêmes.
C'est juste qu'avec VBA Excel, tu vas coder les workbook, sheets, range mais une fois que tu travailles avec ces objets, tu connais ses méthodes, propriétés, etc..
Avec Word, c'est ThisDocument, mais en fait, qque soit l'appli hôte, ce que tu fais avec en tant qu'utilisateur, tu peux "l'automatiser", jusqu'à faire des trucs sympas.

Niveau comparaison, VBA : tu peux des petites choses que vb ne fait pas naturellement (mais que l'on peut coder), et à l'inverse, VB fait beaucoup de choses que VBA ne peut faire, certaines choses, que l'on peut coder, d'autres, impossibles à faire (ou faut être un crack)

@++


  --Mortalino--
Le mystérieux chevalier, "Provençal, le Gaulois"
<!--
Messages postés
148
Date d'inscription
samedi 4 novembre 2006
Statut
Membre
Dernière intervention
4 décembre 2008

Salut mortalino, c'est toujours un plaisir d'ouvrir un débat et d'avoir des avis différents quant au sujet des erreurs et j'attends la réponse prochaine de gregcitt
Quand je suis là tout va mal  
Messages postés
3877
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
23 août 2018
18
Personnellement, je ne vois pas le problème à utiliser les On Error Goto ... et même quelquefois On Error Resume Next


Dans certains cas simples, on peut y aller de IFs qui vérifieront la validité d'une action.

A=10: B=0

C=A / B   'erreur classique de division par 0

on peut régler par If B = 0 then "Rien faire ou MsgBox"


Mais dans certains cas où l'utilisateur peut tout bousiller, il est
préférable d'être prudent et d'y aller avec un On Error Goto Erreur

et d'y aller d'un MsgBox pour terminer en douceur la procédure


Tu peux faire quelque chose comme

On Error goto Erreur

Valeur = FonctionAprobleme


exit sub  ' à mettre avant la gestion d'erreur pour ne pas y passer à toutes les fois

Erreur:   ' ne pas considérer les numéros que je mets

    Select Case err.Number

        Case 123  'on sait ce qui s'est passé

             MsgBox "Vous ne pouvez effectuer cette action parce que..."

        Case 234

             'UneActionàFaire pour régler l'erreur

             Resume 
Next 'on retourne sur la ligne suivante de celle en  problème

        Case 345

             UneActionàFaire et laisser l'utilisateur régler le problème

             Resume  'on retourne sur la ligne à problème

        Case Else

             MsgBox "Erreur non résolue"  ' ici ça sortira de la procédure

    End select

End sub

   

MPi
Messages postés
1
Date d'inscription
dimanche 16 octobre 2005
Statut
Membre
Dernière intervention
2 février 2008

Bonjour


J'avais le meme probleme j'ai trouvé une solution  Je te la donne, si tu l'avais trouvée, cela pourra être utile à d'autre.


Lorsque la gestion de l'erreur est faite, il faut mettre l'instruction

"Resume" (pour que la procedure continue à l'instruction qui a provoqué l'erreur)

"Resume Next" (pour que la procedure continue à l'instruction suivant celle qui a provoqué l'erreur)

"Resume (une étiquette)" (pour que la procedure continue là où on le désire)