Pour info concernant la gestion des erreurs en VB, je me suis mal
exprimé, voici le schéma de ce qu'avait posté le camarade dans sa question
du 19 mai 2010 à 9h34 :
Sub Command1_Click()
On Error Resume Next
Kill deux.une ' err = 424
If Err <> 0 Then MsgBox Err
resume
End Sub
Le "on error resume next" fait comme si l'erreur était à "0", il
l'ignore en la sautant, mais l'erreur n'est pas à "0" dans l'absolu (s'il y
a erreur), donc en effet on peut récupérer l'erreur en dessous 'if err <>
0", mais ceci demeure un principe faux, car seule la première erreur sera
signalée s'il y en avait plusieurs avec davantage de code, ce n'est pas une
écriture appropriée, comme déjà indiqué, ceci pour la raison suivante, deux
cas:
Soit on veut ignorer totalement l'erreur et dans ce cas on ne récupère pas
son numéro et on indique
on error resume next
Soit on veut gérer l'erreur, et dans ce cas on écrit :
on error goto adresse_label_erreur
Précisons ici que gérer son code à "coups d'erreurs" n'est pas non plus
approprié, si on veut par exemple supprimer un fichier il sera plus opportun
de lire les fichiers du répertoire, et de ne le supprimer que s'il existe,
aisnsi on évitera toute gestion d'erreur.
Ceci se comprend car sur le "kill" dans l'exemple il y a une erreur, donc le
"kill" n'est pas exécuté (erreur 424 ici), et ensuite on gère l'erreur...
Mais s'il y avait d'autres instructions, ah ? Exemple :
On Error Resume Next
Kill deux.une ' err = 424 inexistant
i(5) = 10 ' err 9
If Err <> 0 Then MsgBox Err
Et bien l'erreur 9 du "i(5)" ne serait pas signalée au passage, seule
l'erreur 424, la première serait signalée.
Alors pour aérer le code, pour grouper la gestion des erreur, et bien
séparer le code de l'erreur l'exemple de Microsoft parle de lui-même:
On Error GoTo ErrorHandler
Kill deux.une ' err = 424 inexistant
exit sub
ErrorHandler:
On sépare la gestion de l'erreur du code qui l'a produit.
En dernier, le "if" pour tester une erreur n'est pas approprié, en effet,
quand une erreur peut se produit, il peut aussi y avoir des erreurs
inattendues, alors c'est par un "select case" que l'on va les tester,
exemple :
erreur: ' si > 0
select case err
case erreurAttendue1
case erreurAttendue2
case else : erreur inattendue
end select
Ensuite on traite le problème ou on renvoie à la ligne ayant provoqué
l'erreur, après correction du problème évidemment.
Mais en renvoyant, c'est un peu comme un abus de "goto", le pointeur monte,
descend sans cesse, le mieux est de gérer en séquence :
Sub faitLeCode1()
on error goto erreur1
code1 pouvant provoquer l'erreur
exit sub
erreur1: ' si erreur
test, résolution de code1 et fin
end sub
Ainsi on va par une procédure maîtresse piloter de sous-procédure qui
chacune va gérer une erreur, cette méthode est beaucoup plus claire et
demeure dans le principe de VB qui gère les erreurs par procédure ou
fonction, donc localement, et non pas globalement, ce qui va donner :
Sub gestionDuCode()
call faitLeCode1
call FaitLeCode2
end sub
De la sorte tout sera très structuré, chaque gestion d'erreur bien
séparée, chaque appel en retour sera totalement résolu et les erreurs
traitées...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
michdenis
Bonjour,
Ess-tu sûr de ce que tu avances ? '--------------------------------------- donc en effet on peut récupérer l'erreur en dessous 'if err <> 0", mais ceci demeure un principe faux, car seule la première erreur sera signalée '---------------------------------------
Lorsque l'on utilise ON ERROR RESUME NEXT A ) On doit savoir pourquoi on utilise cette gestion d'erreur C'est à dire, avoir déjà identifié la (s) ligne(s) de code qui pourrait poser problème.
B ) Pour chacune de ces lignes, on devrait vérifier si une erreur à été générée et dans l'affirmative, déterminer quelle action devrait être exécutée et surtout remettre Err à ZÉRO. Différente manière de le faire, dont la ligne classique On error goto 0
C ) il ne faut surtout pas utiliser cette méthode de gestion d'erreurs comme raccourci pour se simplifier la vie, en se disant que la procédure va se poursuivre peu importe la ou les erreurs générées.
"LE TROLL" <le a écrit dans le message de groupe de discussion :
Bonjour,
Pour info concernant la gestion des erreurs en VB, je me suis mal exprimé, voici le schéma de ce qu'avait posté le camarade dans sa question du 19 mai 2010 à 9h34 :
Sub Command1_Click() On Error Resume Next Kill deux.une ' err = 424 If Err <> 0 Then MsgBox Err resume End Sub
Le "on error resume next" fait comme si l'erreur était à "0", il l'ignore en la sautant, mais l'erreur n'est pas à "0" dans l'absolu (s'il y a erreur), donc en effet on peut récupérer l'erreur en dessous 'if err <> 0", mais ceci demeure un principe faux, car seule la première erreur sera signalée s'il y en avait plusieurs avec davantage de code, ce n'est pas une écriture appropriée, comme déjà indiqué, ceci pour la raison suivante, deux cas:
Soit on veut ignorer totalement l'erreur et dans ce cas on ne récupère pas son numéro et on indique on error resume next
Soit on veut gérer l'erreur, et dans ce cas on écrit : on error goto adresse_label_erreur
Précisons ici que gérer son code à "coups d'erreurs" n'est pas non plus approprié, si on veut par exemple supprimer un fichier il sera plus opportun de lire les fichiers du répertoire, et de ne le supprimer que s'il existe, aisnsi on évitera toute gestion d'erreur.
Ceci se comprend car sur le "kill" dans l'exemple il y a une erreur, donc le "kill" n'est pas exécuté (erreur 424 ici), et ensuite on gère l'erreur... Mais s'il y avait d'autres instructions, ah ? Exemple :
On Error Resume Next Kill deux.une ' err = 424 inexistant i(5) = 10 ' err 9 If Err <> 0 Then MsgBox Err
Et bien l'erreur 9 du "i(5)" ne serait pas signalée au passage, seule l'erreur 424, la première serait signalée. Alors pour aérer le code, pour grouper la gestion des erreur, et bien séparer le code de l'erreur l'exemple de Microsoft parle de lui-même:
On Error GoTo ErrorHandler Kill deux.une ' err = 424 inexistant exit sub ErrorHandler:
On sépare la gestion de l'erreur du code qui l'a produit.
En dernier, le "if" pour tester une erreur n'est pas approprié, en effet, quand une erreur peut se produit, il peut aussi y avoir des erreurs inattendues, alors c'est par un "select case" que l'on va les tester, exemple :
erreur: ' si > 0 select case err case erreurAttendue1 case erreurAttendue2 case else : erreur inattendue end select
Ensuite on traite le problème ou on renvoie à la ligne ayant provoqué l'erreur, après correction du problème évidemment. Mais en renvoyant, c'est un peu comme un abus de "goto", le pointeur monte, descend sans cesse, le mieux est de gérer en séquence :
Sub faitLeCode1() on error goto erreur1 code1 pouvant provoquer l'erreur exit sub erreur1: ' si erreur test, résolution de code1 et fin end sub
Ainsi on va par une procédure maîtresse piloter de sous-procédure qui chacune va gérer une erreur, cette méthode est beaucoup plus claire et demeure dans le principe de VB qui gère les erreurs par procédure ou fonction, donc localement, et non pas globalement, ce qui va donner :
Sub gestionDuCode() call faitLeCode1 call FaitLeCode2 end sub
De la sorte tout sera très structuré, chaque gestion d'erreur bien séparée, chaque appel en retour sera totalement résolu et les erreurs traitées...
Ess-tu sûr de ce que tu avances ?
'---------------------------------------
donc en effet on peut récupérer l'erreur en dessous 'if err <>
0", mais ceci demeure un principe faux, car seule la première erreur sera
signalée
'---------------------------------------
Lorsque l'on utilise ON ERROR RESUME NEXT
A ) On doit savoir pourquoi on utilise cette gestion d'erreur
C'est à dire, avoir déjà identifié la (s) ligne(s) de code qui pourrait
poser problème.
B ) Pour chacune de ces lignes, on devrait vérifier si une erreur à été générée
et dans l'affirmative, déterminer quelle action devrait être exécutée et surtout
remettre Err à ZÉRO. Différente manière de le faire, dont la ligne classique
On error goto 0
C ) il ne faut surtout pas utiliser cette méthode de gestion d'erreurs comme
raccourci pour se simplifier la vie, en se disant que la procédure va se poursuivre
peu importe la ou les erreurs générées.
"LE TROLL" <le troll@enfer.fr> a écrit dans le message de groupe de discussion :
A80680DE-8264-4523-91F7-0989937471C9@microsoft.com...
Bonjour,
Pour info concernant la gestion des erreurs en VB, je me suis mal
exprimé, voici le schéma de ce qu'avait posté le camarade dans sa question
du 19 mai 2010 à 9h34 :
Sub Command1_Click()
On Error Resume Next
Kill deux.une ' err = 424
If Err <> 0 Then MsgBox Err
resume
End Sub
Le "on error resume next" fait comme si l'erreur était à "0", il
l'ignore en la sautant, mais l'erreur n'est pas à "0" dans l'absolu (s'il y
a erreur), donc en effet on peut récupérer l'erreur en dessous 'if err <>
0", mais ceci demeure un principe faux, car seule la première erreur sera
signalée s'il y en avait plusieurs avec davantage de code, ce n'est pas une
écriture appropriée, comme déjà indiqué, ceci pour la raison suivante, deux
cas:
Soit on veut ignorer totalement l'erreur et dans ce cas on ne récupère pas
son numéro et on indique
on error resume next
Soit on veut gérer l'erreur, et dans ce cas on écrit :
on error goto adresse_label_erreur
Précisons ici que gérer son code à "coups d'erreurs" n'est pas non plus
approprié, si on veut par exemple supprimer un fichier il sera plus opportun
de lire les fichiers du répertoire, et de ne le supprimer que s'il existe,
aisnsi on évitera toute gestion d'erreur.
Ceci se comprend car sur le "kill" dans l'exemple il y a une erreur, donc le
"kill" n'est pas exécuté (erreur 424 ici), et ensuite on gère l'erreur...
Mais s'il y avait d'autres instructions, ah ? Exemple :
On Error Resume Next
Kill deux.une ' err = 424 inexistant
i(5) = 10 ' err 9
If Err <> 0 Then MsgBox Err
Et bien l'erreur 9 du "i(5)" ne serait pas signalée au passage, seule
l'erreur 424, la première serait signalée.
Alors pour aérer le code, pour grouper la gestion des erreur, et bien
séparer le code de l'erreur l'exemple de Microsoft parle de lui-même:
On Error GoTo ErrorHandler
Kill deux.une ' err = 424 inexistant
exit sub
ErrorHandler:
On sépare la gestion de l'erreur du code qui l'a produit.
En dernier, le "if" pour tester une erreur n'est pas approprié, en effet,
quand une erreur peut se produit, il peut aussi y avoir des erreurs
inattendues, alors c'est par un "select case" que l'on va les tester,
exemple :
erreur: ' si > 0
select case err
case erreurAttendue1
case erreurAttendue2
case else : erreur inattendue
end select
Ensuite on traite le problème ou on renvoie à la ligne ayant provoqué
l'erreur, après correction du problème évidemment.
Mais en renvoyant, c'est un peu comme un abus de "goto", le pointeur monte,
descend sans cesse, le mieux est de gérer en séquence :
Sub faitLeCode1()
on error goto erreur1
code1 pouvant provoquer l'erreur
exit sub
erreur1: ' si erreur
test, résolution de code1 et fin
end sub
Ainsi on va par une procédure maîtresse piloter de sous-procédure qui
chacune va gérer une erreur, cette méthode est beaucoup plus claire et
demeure dans le principe de VB qui gère les erreurs par procédure ou
fonction, donc localement, et non pas globalement, ce qui va donner :
Sub gestionDuCode()
call faitLeCode1
call FaitLeCode2
end sub
De la sorte tout sera très structuré, chaque gestion d'erreur bien
séparée, chaque appel en retour sera totalement résolu et les erreurs
traitées...
Ess-tu sûr de ce que tu avances ? '--------------------------------------- donc en effet on peut récupérer l'erreur en dessous 'if err <> 0", mais ceci demeure un principe faux, car seule la première erreur sera signalée '---------------------------------------
Lorsque l'on utilise ON ERROR RESUME NEXT A ) On doit savoir pourquoi on utilise cette gestion d'erreur C'est à dire, avoir déjà identifié la (s) ligne(s) de code qui pourrait poser problème.
B ) Pour chacune de ces lignes, on devrait vérifier si une erreur à été générée et dans l'affirmative, déterminer quelle action devrait être exécutée et surtout remettre Err à ZÉRO. Différente manière de le faire, dont la ligne classique On error goto 0
C ) il ne faut surtout pas utiliser cette méthode de gestion d'erreurs comme raccourci pour se simplifier la vie, en se disant que la procédure va se poursuivre peu importe la ou les erreurs générées.
"LE TROLL" <le a écrit dans le message de groupe de discussion :
Bonjour,
Pour info concernant la gestion des erreurs en VB, je me suis mal exprimé, voici le schéma de ce qu'avait posté le camarade dans sa question du 19 mai 2010 à 9h34 :
Sub Command1_Click() On Error Resume Next Kill deux.une ' err = 424 If Err <> 0 Then MsgBox Err resume End Sub
Le "on error resume next" fait comme si l'erreur était à "0", il l'ignore en la sautant, mais l'erreur n'est pas à "0" dans l'absolu (s'il y a erreur), donc en effet on peut récupérer l'erreur en dessous 'if err <> 0", mais ceci demeure un principe faux, car seule la première erreur sera signalée s'il y en avait plusieurs avec davantage de code, ce n'est pas une écriture appropriée, comme déjà indiqué, ceci pour la raison suivante, deux cas:
Soit on veut ignorer totalement l'erreur et dans ce cas on ne récupère pas son numéro et on indique on error resume next
Soit on veut gérer l'erreur, et dans ce cas on écrit : on error goto adresse_label_erreur
Précisons ici que gérer son code à "coups d'erreurs" n'est pas non plus approprié, si on veut par exemple supprimer un fichier il sera plus opportun de lire les fichiers du répertoire, et de ne le supprimer que s'il existe, aisnsi on évitera toute gestion d'erreur.
Ceci se comprend car sur le "kill" dans l'exemple il y a une erreur, donc le "kill" n'est pas exécuté (erreur 424 ici), et ensuite on gère l'erreur... Mais s'il y avait d'autres instructions, ah ? Exemple :
On Error Resume Next Kill deux.une ' err = 424 inexistant i(5) = 10 ' err 9 If Err <> 0 Then MsgBox Err
Et bien l'erreur 9 du "i(5)" ne serait pas signalée au passage, seule l'erreur 424, la première serait signalée. Alors pour aérer le code, pour grouper la gestion des erreur, et bien séparer le code de l'erreur l'exemple de Microsoft parle de lui-même:
On Error GoTo ErrorHandler Kill deux.une ' err = 424 inexistant exit sub ErrorHandler:
On sépare la gestion de l'erreur du code qui l'a produit.
En dernier, le "if" pour tester une erreur n'est pas approprié, en effet, quand une erreur peut se produit, il peut aussi y avoir des erreurs inattendues, alors c'est par un "select case" que l'on va les tester, exemple :
erreur: ' si > 0 select case err case erreurAttendue1 case erreurAttendue2 case else : erreur inattendue end select
Ensuite on traite le problème ou on renvoie à la ligne ayant provoqué l'erreur, après correction du problème évidemment. Mais en renvoyant, c'est un peu comme un abus de "goto", le pointeur monte, descend sans cesse, le mieux est de gérer en séquence :
Sub faitLeCode1() on error goto erreur1 code1 pouvant provoquer l'erreur exit sub erreur1: ' si erreur test, résolution de code1 et fin end sub
Ainsi on va par une procédure maîtresse piloter de sous-procédure qui chacune va gérer une erreur, cette méthode est beaucoup plus claire et demeure dans le principe de VB qui gère les erreurs par procédure ou fonction, donc localement, et non pas globalement, ce qui va donner :
Sub gestionDuCode() call faitLeCode1 call FaitLeCode2 end sub
De la sorte tout sera très structuré, chaque gestion d'erreur bien séparée, chaque appel en retour sera totalement résolu et les erreurs traitées...