VB6 Gestion d'erreurs sur tout le programme
Résolu/Fermé
Utilisateur anonyme
-
17 juin 2008 à 11:34
Derdonn Messages postés 13 Date d'inscription jeudi 15 octobre 2009 Statut Membre Dernière intervention 29 octobre 2013 - 9 sept. 2011 à 18:13
Derdonn Messages postés 13 Date d'inscription jeudi 15 octobre 2009 Statut Membre Dernière intervention 29 octobre 2013 - 9 sept. 2011 à 18:13
A voir également:
- VB6 Gestion d'erreurs sur tout le programme
- Programme demarrage windows 10 - Guide
- Vb6 - Télécharger - Divers Utilitaires
- Logiciel gestion photos - Guide
- Programme démarrage windows 10 - Guide
- Cette action ne peut pas être réalisée car le fichier est ouvert dans un autre programme - Guide
8 réponses
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
17 juin 2008 à 12:07
17 juin 2008 à 12:07
Oui c'est préferable et en fin de fonction du fait le If Err.Number > 0 Then ...
Tu peux récupérer ainsi le numéro et la description de l'erreur et les passer en paramètre à une procédure public:
;o)
Polux
Tu peux récupérer ainsi le numéro et la description de l'erreur et les passer en paramètre à une procédure public:
Function myFonction() On Error Resume Next 'le code ... If Err.Number > 0 Then Call procErrmsg(Err.Number, Err.Description) Exit Fuction End If End Function ---------------------------------- Sub procErrmsg(ByVal numErr As Integer, ByVal msgErr As String) MsgBox msgErr, VbExclamation, "Erreur: " & numErr End Sub
;o)
Polux
"Merci, je connais .NET. " ( ? ) -->
désolé d'avoir mal interpreté ta phrase : "Pourquoi en .Net les erreurs seraient-elles mieux gérées ??? " j'avais compris : Pourquoi, en .Net les erreurs seraient-elles mieux gérées ?
"Un Goto gErr envoie directement à gErr: sans executer tout le code. Ce qui peut être génant" -->
ou peu prendre tout son interret. et puis le resume next positionné après l'étiquette gErr: permet de revenir dans des cas définits. Un point d'arret après l'étiquette permet de voir quand une erreur est détectée (lors du debugage), dès quelle l'est.
"Je ne vois pas beaucoup de différences entre un try/catch" -->
si quand même ! une grosse que je connais : avec le try catch il ya un système de remontée d'erreur dans la pile d'appels des fonctions, les erreurs peuvent etre gérées au niveau que tu veux, je ne me rappelle pas super avec .NET non plus mais il doit faire comme les autres je pense !.
"bonne soirée" -->
merci pareillement.
désolé d'avoir mal interpreté ta phrase : "Pourquoi en .Net les erreurs seraient-elles mieux gérées ??? " j'avais compris : Pourquoi, en .Net les erreurs seraient-elles mieux gérées ?
"Un Goto gErr envoie directement à gErr: sans executer tout le code. Ce qui peut être génant" -->
ou peu prendre tout son interret. et puis le resume next positionné après l'étiquette gErr: permet de revenir dans des cas définits. Un point d'arret après l'étiquette permet de voir quand une erreur est détectée (lors du debugage), dès quelle l'est.
"Je ne vois pas beaucoup de différences entre un try/catch" -->
si quand même ! une grosse que je connais : avec le try catch il ya un système de remontée d'erreur dans la pile d'appels des fonctions, les erreurs peuvent etre gérées au niveau que tu veux, je ne me rappelle pas super avec .NET non plus mais il doit faire comme les autres je pense !.
"bonne soirée" -->
merci pareillement.
choubaka
Messages postés
39375
Date d'inscription
jeudi 4 avril 2002
Statut
Modérateur
Dernière intervention
14 avril 2024
2 100
17 juin 2008 à 11:44
17 juin 2008 à 11:44
Salut
il suffit de créer une procédure publique dans un module séparé.
il te suffira alors d'effectuer un call de cette procédure
il suffit de créer une procédure publique dans un module séparé.
il te suffira alors d'effectuer un call de cette procédure
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
17 juin 2008 à 11:56
17 juin 2008 à 11:56
Bonjour,
Bien qu'étant autorisé en VB le "On Error Goto..." n'est pas très "propre" ni très fiable. Il est préférable d'utiliser "On Error Resume Next" et récupérer l'erreur en faisant :
If Err.Number > 0 Then .... End If.
C'est un avis personnel, mais par expérience je n'utilise plus le "On Error Goto".
;o)
Bien qu'étant autorisé en VB le "On Error Goto..." n'est pas très "propre" ni très fiable. Il est préférable d'utiliser "On Error Resume Next" et récupérer l'erreur en faisant :
If Err.Number > 0 Then .... End If.
C'est un avis personnel, mais par expérience je n'utilise plus le "On Error Goto".
;o)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
17 juin 2008 à 12:52
17 juin 2008 à 12:52
Err.Number renvoit le numéro de l'erreur, il n'y a pas besoin de l'initialiser. Si il n'y a pas d'erreur ça renvoit 0 tout simplement.
Effectivement, il n'est pas nécessaire de coller On Error Resume Next partout dans le code. Il faut cibler les procédures et fonctions pouvant lever une éxception.
Bon courage pour la suite.
;o)
Polux
Effectivement, il n'est pas nécessaire de coller On Error Resume Next partout dans le code. Il faut cibler les procédures et fonctions pouvant lever une éxception.
Bon courage pour la suite.
;o)
Polux
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
17 juin 2008 à 14:18
17 juin 2008 à 14:18
De rien, c'est avec plaisir
Bonne continuation.
;o)
Bonne continuation.
;o)
Bonjour
désolé pour le vieux up,
Cependant :
J'ai regardé la date : il serait temps de passer à .NET :-D, ou un truc qui gère un pepu mieux les erreurs.
Vous me direz :
Comment es-tu tombé sur ce message si tu ne t'interressais pas à "VB6 Gestion d'erreurs sur tout le programme" ?, héhé c'est bien ce que je cherchais hélas ^^ ( Office ... , vieux programmes ...)
... Merci égallement à toi.
désolé pour le vieux up,
Cependant :
J'ai regardé la date : il serait temps de passer à .NET :-D, ou un truc qui gère un pepu mieux les erreurs.
Vous me direz :
Comment es-tu tombé sur ce message si tu ne t'interressais pas à "VB6 Gestion d'erreurs sur tout le programme" ?, héhé c'est bien ce que je cherchais hélas ^^ ( Office ... , vieux programmes ...)
... Merci égallement à toi.
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
15 oct. 2008 à 16:12
15 oct. 2008 à 16:12
Salut,
Pourquoi en .Net les erreurs seraient-elles mieux gérées ???
Il suffit de se donner la peine de vouloir les gérer en VB.
Bonne continuation.
;o)
Pourquoi en .Net les erreurs seraient-elles mieux gérées ???
Il suffit de se donner la peine de vouloir les gérer en VB.
Bonne continuation.
;o)
gg2laba
>
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
15 oct. 2008 à 16:36
15 oct. 2008 à 16:36
J'ai oublier de préciser sinon euh en fait à mes souvenirs "on error goto" est plus pratique (par rapport à "on error resume next") : le "on error resume next" de cette façon ne previent pas lors d'une erreur même lors du debugage. voilà ce que je propose pour les prochains :
Private Sub maSub()
On Error GoTo gErr
...
gErr:
If Err.Number = 2452 Then 'pas de parent
Else
Resume Next
End Sub
après question propreté .. je ne suis pas trop monsieur propre non plus :-p.
après avoir vu le message de Polux31 -->
Je vois que tu est très attentif sur le forum Polux31, merci à toi.
pour la gestion des erreurs, je suis d'accord que on peut faire ca bien quand même, mais pour moi un "on error goto/resume" ca ne vaut pas un try/catch ! après c'est peut-etre possible de faire ca en VB6 (pas simple). mais même pour moi .NET > VB6 ( pas forcement en tout points ) sans problème, si tu n'a jamais essayé c'est l'ocasion en plus il ya des versions gratuites !
salut !
Private Sub maSub()
On Error GoTo gErr
...
gErr:
If Err.Number = 2452 Then 'pas de parent
Else
Resume Next
End Sub
après question propreté .. je ne suis pas trop monsieur propre non plus :-p.
après avoir vu le message de Polux31 -->
Je vois que tu est très attentif sur le forum Polux31, merci à toi.
pour la gestion des erreurs, je suis d'accord que on peut faire ca bien quand même, mais pour moi un "on error goto/resume" ca ne vaut pas un try/catch ! après c'est peut-etre possible de faire ca en VB6 (pas simple). mais même pour moi .NET > VB6 ( pas forcement en tout points ) sans problème, si tu n'a jamais essayé c'est l'ocasion en plus il ya des versions gratuites !
salut !
Polux31
Messages postés
6917
Date d'inscription
mardi 25 septembre 2007
Statut
Membre
Dernière intervention
1 novembre 2016
1 204
>
gg2laba
15 oct. 2008 à 16:52
15 oct. 2008 à 16:52
Merci, je connais .NET.
Pour info: Le On Error Resume Next permet de récupérer l'erreur de la même manière que On Error Goto. Le Resume Next laisse le code s'executer jusqu'à l'interception de l'erreur par un If Err.Numbre <> 0 Then ... par exemple. Un Goto gErr envoie directement à gErr: sans executer tout le code. Ce qui peut être génant
Je ne vois pas beaucoup de différences entre un try/catch et un On Error Goto ou Resume Next. Ni en quoi c'est mieux. L'un et l'autre servant à gérer des exceptions. Le tout c'est de se donner la peine de les utiliser.
bonne soirée
;o)
Pour info: Le On Error Resume Next permet de récupérer l'erreur de la même manière que On Error Goto. Le Resume Next laisse le code s'executer jusqu'à l'interception de l'erreur par un If Err.Numbre <> 0 Then ... par exemple. Un Goto gErr envoie directement à gErr: sans executer tout le code. Ce qui peut être génant
Je ne vois pas beaucoup de différences entre un try/catch et un On Error Goto ou Resume Next. Ni en quoi c'est mieux. L'un et l'autre servant à gérer des exceptions. Le tout c'est de se donner la peine de les utiliser.
bonne soirée
;o)
Derdonn
Messages postés
13
Date d'inscription
jeudi 15 octobre 2009
Statut
Membre
Dernière intervention
29 octobre 2013
9 sept. 2011 à 18:13
9 sept. 2011 à 18:13
Parce qu'en 2011 y en a encore comme moi qui galèrent à devoir reprendre des projets en VB6 et qui se reposent des question existentielles que mille personnes se sont déjà posés bien avant. Et aussi parce que ce topic apparait en haut du moteur de recherche sans complètement répondre à la question qui brûle les lèvres, je me permet de compléter :
OUI il est obligatoire de mettre une directive "on error" AU MINIMUM dans le sub main, dans le Class_Terminate et dans CHAQUE gestionnaire d'événement, sans quoi vous avez un exécutable qui crash au moindre petit pet de travers.
Source : http://www.vb6.us/tutorials/error-handling "http://www.vb6.us/tutorials/error-handling"
La fonction de Pollux31 semble la bonne méthode pour faire ça par copier coller de partout et faire que les erreurs soient simplement loggés dans un fichiers sans causer plus de dégâts. J'en ai donc fait un module standard que j'inclue dans mes projets.
###########GestionErreur.bas###########
'Module de gestion des erreurs v1.0
'Private Sub Command1_Click()
' On Error Resume Next
'
' ...
'
' If Err.Number > 0 Then Call procErrmsg(Err.Number, Err.Description)
'End Sub
Function sur_1_ligne(str As String) As String
sur_1_ligne = Replace(str, vbCrLf, "<CrLf>")
sur_1_ligne = Replace(str, vbCr, "<Cr>")
sur_1_ligne = Replace(str, vbLf, "<Lf>")
End Function
Sub procErrmsg(ByVal numErr As Integer, ByVal msgErr As String)
On Error Resume Next
Open App.Path & "\errors.log" For Append As #1
Print #1, Date & " - " & Time & " - Erreur " & numErr & ": " & sur_1_ligne(msgErr)
Close #1
End Sub
#################################
OUI il est obligatoire de mettre une directive "on error" AU MINIMUM dans le sub main, dans le Class_Terminate et dans CHAQUE gestionnaire d'événement, sans quoi vous avez un exécutable qui crash au moindre petit pet de travers.
Source : http://www.vb6.us/tutorials/error-handling "http://www.vb6.us/tutorials/error-handling"
La fonction de Pollux31 semble la bonne méthode pour faire ça par copier coller de partout et faire que les erreurs soient simplement loggés dans un fichiers sans causer plus de dégâts. J'en ai donc fait un module standard que j'inclue dans mes projets.
###########GestionErreur.bas###########
'Module de gestion des erreurs v1.0
'Private Sub Command1_Click()
' On Error Resume Next
'
' ...
'
' If Err.Number > 0 Then Call procErrmsg(Err.Number, Err.Description)
'End Sub
Function sur_1_ligne(str As String) As String
sur_1_ligne = Replace(str, vbCrLf, "<CrLf>")
sur_1_ligne = Replace(str, vbCr, "<Cr>")
sur_1_ligne = Replace(str, vbLf, "<Lf>")
End Function
Sub procErrmsg(ByVal numErr As Integer, ByVal msgErr As String)
On Error Resume Next
Open App.Path & "\errors.log" For Append As #1
Print #1, Date & " - " & Time & " - Erreur " & numErr & ": " & sur_1_ligne(msgErr)
Close #1
End Sub
#################################
17 juin 2008 à 12:20
dernière petite question, le Err.number retombe-t-il automatiquement à 0 à la sortie de la fonction?