Gestion des erreur bis

Le
LE TROLL
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

Cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
michdenis
Le #22143151
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"
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...

Cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.
Publicité
Poster une réponse
Anonyme