on error resume next et on error go to, différence?

Bonjour,

Je comprends pas bien la différence de ces deux instructions.
Dans un cas comme dans l'autre il ne traite pas les lignes entre,non? pour :

Code:

---

1 2 3

On error resume next ' On désactive la gestion des erreur ... On Error GoTo 0 ' On réactive la gestion des erreurs

---

et

Code:

---

1 2 3

On error Go to traitement_erreur .. traitement_erreur :

---

de plus avec On error resume next, on peut aussi traiter l'erreure, non?
avec un

Code:

---

1 2 3 4

iIf Err.Number > 0 Then .... err.clear End If.

---

Dans quel cas utiliser l'un ou l'autre?
A part pour la gestion des fichiers,dossiers, division par 0, dans quel cas utiliser la gestion des erreurs, par exemple?

NAth

Salut

Le

Code:

---

On error resume next

---

ne doit être utilisé que dans 2 cas a mon avis,
1er cas, si tu veux faire la gestion ponctuel d'une erreur, un division qui risque de contenir 0, dans ce cas l'erreur ne génèrera pas de message et tu pourra la récupérer en gérant la valeur de

Code:

---

err.number

---

2eme cas, si tu es sur que ton code est bien rodé, que tu souhaite le distribuer, mais que tu ne souhaite pas que l'utilisateur tombe sur un message lui proposant le debugage en cas de survenu d'une erreur que tu n'aurais pas géré. L'avantage réside lorsque les utilisateur ne sont pas capable d'interpréter ce type de message, ils ne sont donc pas perturbé par sont apparition. Mais attention car le très très gros risque c'est que les résultat de ton code soient totalement faux et que personne ne s'en rende compte.... Il faut donc utiliser le goto resume next avec discernement.

Dans le cas on ton application est utiliser par des profane et que tu ne souhaite justement pas que le message lié au debugage s'affiche, tu as la possibilité lorsqu'une erreur survient de dirigé ton code vers un point particulier de ton code, c'est le cas ici

Code:

---

1 2 3 4 5

On error Goto traitement_erreur .. Exit sub traitement_erreur :

---

Ne pas oublier le Exit sub/function qui permet de ne pas traiter ce code arrivé a la fin de ta procédure.
a la suite de traitement_erreur : tu pourras au besoin afficher un message de ton cru en function encore une fois du numéro d'erreur, avec une explication claire de ce que doit faire l'utilisateur, le prévenant par exemple qu'une erreur inconnu est apparu et qu'il doit te contacter avec le numéro 'erreur que tu ajoute dans ton message, voir l'aide excel je crois qu'il y a des exemple.

Le code qui suit traitement_erreur est generique a toutes les erreur, mais tu pourra faire evolué se code avec un select case ou des if,elseif,else en fonction de err.number.

La gestion d'erreur est souvent négligé (ça m'arrive souvent aussi) et c'est une erreur justement, on voit souvent sur le fofo des gens novices qui attaquent leur code par "On erro goto next" et ensuite ils ne comprennent pas pourquoi le code ne fait pas ce qu'ils veulent... sans aucun message d'alerte ni gestion d'erreur c'est évident.

A++
Qwaz

ok merci, je commence à mieux comprendre...mais pas tout à fait encore ;)

mais une question encore, faut-il employer le Err.clear avec

Code:

---

1 2 3 4 5

On error Goto traitement_erreur .. Exit sub traitement_erreur :

---

mais bon si on fait :

Code:

---

1 2 3 4 5 6

On error resume next x = y/ 0 if err.number > 0 then ... end if

---

cela revient au meme, un peu que d'utiliser le on error resume next? non?
ou est-ce que la différence est que dans ce cas, on peut avoir un msg d'erreur, puis le code qui continue de s'éxecuter, tandis qu'avec le on error goto traitement_erreur le code s'arrête net?:lol:

En fait le on error goto, sert simplemet à informer l'utilisateur avec un langage un peu moins barbare qu'il y'a un problème et l'empêcher de pouvoir débuguer?

Dans un cas réduis comme tu le propose, oui le code serait similaire, mais il faut voir a une échelle plus importante avec plusieurs situation qui risque de generer des erreurs, dans un tel cas plutôt que de mettre

Code:

---

1 2 3

on error resume next ... on error goto 0

---

a chaque fois, il sera préférable de gerer tous les types d'erreurs que pourrait générer ton code en utilisant le

Code:

---

on error goto traitement_erreur

---

en tout debut de code.

Ne pas oublié dans la section protegé en bas d'utiliser resume next pour que le code continu a l'endroit ou il c'est arrête si telle est ta volonté bien sur.

A++
Qwaz

Bonsoir Qwazerty
j'ai lu ce post très clair et je me pose une question (ne riez pas): si je veux router comme tu proposes vers un traitement_erreur en cas d'erreur, qui consiste à alerter par une msgbox avec deux instructions stop ou encore, comment je peux retourner à l'éxécution du programme une fois le message lu (bouton ok = encore) ?

Merci bcp!

Bonjour,

Citation:

---

Envoyé par Polygos

j'ai lu ce post très clair et je me pose une question (ne riez pas): si je veux router comme tu proposes vers un traitement_erreur en cas d'erreur, qui consiste à alerter par une msgbox avec deux instructions stop ou encore, comment je peux retourner à l'éxécution du programme une fois le message lu (bouton ok = encore)

---

L'instruction qui permet de reprendre là où l'erreur s'est produit est Resume

Je voudrais préciser qu'il ne faut utiliser la gestion d'erreur que si on ne peut pas éviter qu'elles se produisent avec une gestion en amont.

Citation:

---

Envoyé par Patrice740

Bonjour,

L'instruction qui permet de reprendre là où l'erreur s'est produit est Resume

Je voudrais préciser qu'il ne faut utiliser la gestion d'erreur que si on ne peut pas éviter qu'elles se produisent avec une gestion en amont.

---

Bonjour Patrice
Cette fois l'erreur m'es très utile.
Il s'agit d'un transfert de photos d'un répertoire à un autre.
Dons si une photo attentue n'est pas trouvée, je voudrais voir le message qui me l'identifie, car ce cas doit être rare (ce peut être aussi car son format en png n'est pas le jpg attendu, etc.) d'où le besoin d'identifier l'arrêt et de route vers une simple box qui m'indique l'article dont la photo n'est pas conforme.

Quelqu'un peut il m'apprendre ?

Citation:

---

Envoyé par Polygos

Il s'agit d'un transfert de photos d'un répertoire à un autre.
Dons si une photo attentue n'est pas trouvée, je voudrais voir le message qui me l'identifie, car ce cas doit être rare (ce peut être aussi car son format en png n'est pas le jpg attendu, etc.) d'où le besoin d'identifier l'arrêt et de route vers une simple box qui m'indique l'article dont la photo n'est pas conforme.

---

Comme je t'ai dit, il ne faut pas attendre que l'erreur se produise pour la gérer !
Il faut anticiper en vérifiant que le fichier existe avant d'essayer de le transférer. Pour ça il y a Dir().

Citation:

---

Envoyé par Patrice740

Comme je t'ai dit, il ne faut pas attendre que l'erreur se produise pour la gérer !
Il faut anticiper en vérifiant que le fichier existe avant d'essayer de le transférer. Pour ça il y a Dir().

---

Merci de l'info, mais dans le processus de mon code, faire ressortir l'erreur est bien plus systématique pour moi.


Si je veux controler la présence du fichier avant de le déplacer alors j'écris le test présence photo qui doit m'alerter

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

For i = PL To DL   If ws1.Cells(i, 122) > 0 Then 'condition de base)     'Chemin de stockage de la photo DN, détourée, recadrée,   chemin = Cells(i, 63).Value   'Test présence photo: En cellule59, le nom du fichier photo, xxx.jpg rep = Dir("chemin" & Cells(i, 59).Value) If rep = "" Then MsgBox (cells(i,59&"photo absente") Else End If     nouveauchemin = "\\Station-serveur\MAISON DELAHAYE\PHOTOS & FT FOURNISSEURS\..PHOTOS DU SITE\PHOTOS PRIMAIRES\DN CENTRALISEES\"     Dim Fso As Object Set Fso = CreateObject("scripting.filesystemobject") Fso.Copyfile chemin, "\\Station-serveur\MAISON DELAHAYE\PHOTOS & FT FOURNISSEURS\..PHOTOS DU SITE\PHOTOS PRIMAIRES\DN CENTRALISEES\", Overwrite     Else   End If     Next i   End Sub

---

C'est correct ?

Citation:

---

Envoyé par Polygos

Tan pis si tu ne veux pas me répondre, merci quand même.

---

?????????????? J'ai répondu à toutes tes dernières questions !!!!

Si tu veux une solution sous forme VBA, il faut le publier ton code en précisant où est le problème !

bonjour
le on error resume next oblige le développeur à gérer toute les ligne de code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

On Error Resume Next Instruction1 if Err then msgbox Err.description Err.clear end if Instruction2 if Err then msgbox Err.description Err.clear end if Instruction3 if Err then msgbox Err.description Err.clear end if On Error Goto 0

---

On Error Goto permet de centralise la gestion des Erreur!
le code suivant fait la même chose que le code précédant!

Code:

---

1 2 3 4 5 6 7 8 9 10 11

On Error goto Erreur Instruction1 Instruction2 Instruction3 goto Fin Erreur: msgbox Err.description Err.clear resume next FIn: On Error Goto 0

---

dans d'autre langage on parle d'exception!
la gestion des exception doit resté exceptionnelle!
tous les cas susceptible de générer des erreur doivent être évalué systématiquement!

Bonjour,

Citation:

---

Envoyé par Thumb down

le code suivant fait la même chose que le code précédant!

---

Eh bien Non, car il ne permet pas de savoir laquelle des 3 instructions à généré l'erreur.

D'autre part ces 2 exemples ne traitent pas l'erreur, il se contentent de prévenir et de l'ignorer.
Un bon traitement d'erreur n'utilise pas Resume next, il choisit entre Resume et End.

Il est fréquent d'utiliser On Error Resume Next pour une instruction particulière suivi de On Error Goto 0 pour laisser la possibilité à une erreur de se produire.
Dans la très grande majorité des cas, il n'y a pas d'analyse, on suppose que l'erreur qui s'est produite est celle à laquelle on s'attendait ce qui parfois entraine des comportements inattendus.

Re,

Citation:

---

Envoyé par Polygos

C'est correct ?

---

Il faut éviter de mettre dans les boucles les instructions qui ne doivent être exécutée qu'une fois :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Option Explicit Sub test() Dim ws1 As Worksheet Dim PL As Long, DL As Long, i As Long Dim Fso As Object Dim msg As String Dim cheminSource As String Dim cheminCible As String Dim nomFichier As String   '.... ' Set Fso = CreateObject("scripting.filesystemobject") cheminCible = "\\Station-serveur\MAISON DELAHAYE\PHOTOS & FT FOURNISSEURS\..PHOTOS DU SITE\PHOTOS PRIMAIRES\DN CENTRALISEES\" For i = PL To DL If ws1.Cells(i, 122) > 0 Then 'condition de base) 'Chemin de stockage de la photo DN, détourée, recadrée, cheminSource = Cells(i, 63).Value nomFichier = Cells(i, 59).Value 'Test présence photo: En cellule59, le nom du fichier photo, xxx.jpg If Dir(cheminSource & nom) = "" Then msg = msg & vbCrLf & "- " & nomFichier Else Fso.Copyfile cheminSource & nomFichier, cheminCible & nomFichier, True End If End If Next i If msg > "" Then MsgBox "Photo(s) absente(s) :" & msg, vbCritical   End Sub

---

Bonjour,
A toutes fins utiles, je signale qu'il existe sur Developpez.com, une multitude de tutoriels très complets.
Je conseille donc la lecture de La gestion des erreurs dans Excel

Citation:

---

Envoyé par Patrice740

Bonjour,

Eh bien Non, car il ne permet pas de savoir laquelle des 3 instructions à généré l'erreur.

D'autre part ces 2 exemples ne traitent pas l'erreur, il se contentent de prévenir et de l'ignorer.
Un bon traitement d'erreur n'utilise pas Resume next, il choisit entre Resume et End.

Il est fréquent d'utiliser On Error Resume Next pour une instruction particulière suivi de On Error Goto 0 pour laisser la possibilité à une erreur de se produire.
Dans la très grande majorité des cas, il n'y a pas d'analyse, on suppose que l'erreur qui s'est produite est celle à laquelle on s'attendait ce qui parfois entraine des comportements inattendus.

---

Bonjour,
Je n'avais pas l'intention définir une gestion parfaite des erreurs.
Les deux exemples font exectement la même chose c'est à dire rien ce qui est généralement le cas dans la gestion des erreurs !

Il est possible de numéroter les lignes et loguer dans un fichier l'erreur et le Nº de ligne.

La gestion des erreurs est et doit rester exceptionnel, comme je le disais plus haut. La gestion des erreurs doit impérativement être un mode d'échappement pas un moyen de contourner l'erreur ce qui aurait pour effet un résultat imprévisible !

Un message d'erreur est préférable à un résultat loufoque !

Citation:

---

Envoyé par Thumb down

.... La gestion des erreurs doit impérativement être un mode d'échappement pas un moyen de contourner l'erreur ce qui aurait pour effet un résultat imprévisible !

---

Dans gestion des erreurs, il y a "gestion" ! Et gérer c'est pas ignorer !
Tes 2 exemples ne gèrent rien, ils affichent un message en cas d'erreur mais
ils laissent continuer le programme au lieu de le stopper ou de résoudre l'erreur :
ils ignorent les conséquences de l'erreur (ils contournent l'erreur) et c'est ça qui donne des résultats inattendus voire catastrophiques !

Errare humanum est, perseverare diabolicum est

Citation:

---

Envoyé par Patrice740

Dans gestion des erreurs, il y a "gestion" ! Et gérer c'est pas ignorer !
Tes 2 exemples ne gèrent rien, ils affichent un message en cas d'erreur mais
ils laissent continuer le programme au lieu de le stopper ou de résoudre l'erreur :
ils ignorent les conséquences de l'erreur (ils contournent l'erreur) et c'est ça qui donne des résultats inattendus voire catastrophiques !

Errare humanum est, perseverare diabolicum est

---

je n'es plus de mots pour te dire qu'on résous jamais une erreur, on évalue les risques pour placer l'application dans les meilleurs disposition!

par exemple je vérifie si l'imprimante est disponible et prête à imprimer mais un fois c'est précaution prise on est pas dans l'imprimante et une erreur indépendante de ma volonté est possible {EXCEPTION}

on ne résous pas l'échappe!

on est au-moins d’accord sur un point l’exemple que j'ai donné ne fait rien! on ne doit du reste jamais rein faire avec un erreur l’acquitter et annuler tout le traitement!

on ne gère pas les erreur on les subits! gérer le Erreurs c'est évaluer le risques pour pour ne pas solliciter le debugeur!

Citation:

---

Dans la très grande majorité des cas, il n'y a pas d'analyse, on suppose que l'erreur qui s'est produite est celle à laquelle on s'attendait ce qui parfois entraine des comportements inattendus.

---

C'est à mon sens et j'imgine au tiens, une hérésie, si on s'attend à l'erreur pourquoi ne rien mettre en œuvre pour l'éviter et voir des comportements inattendus?
Tu t'evertu montrer un désaccord avec mes propos , alors que je voulais démontrer qu'une gestion centralisée des messages d'erreur était préférable à un on error resume nex!

En conclusion il faut banire de ses codes le on error sauf pour le cas hardware réseau, imprimante etc...
Tout ce qui n'est pas prévisible !