Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic Comment savoir d'ou vient une erreur ???

Comment savoir d'ou vient une erreur ???

9 réponses
Avatar
X
Bonjour,

J'ai :

6
dépassement de capacité
projet 1

Lol, dépassement de capacité de quoi, où, comment faire ???

Merci beaucoup, au revoir et à bientôt :o)
------
Site logiciels
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
Site perso
http://irolog.free.fr/joe/index.htm
------------------------------------------------------------------------------------
Signaler un problème avec ce contenu

9 réponses

Supprimer
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
Avatar
Aski
Salutatoi X,

Tu as donc déclaré :

Bonjour,

J'ai :

6
dépassement de capacité
projet 1

Lol, dépassement de capacité de quoi, où, comment faire ???

Merci beaucoup, au revoir et à bientôt :o)



Ajoute une gestion d'erreur dans chaque procédure.

Private Function Toto as boolean
on error goto Erreur
...
'ton code
exit function

Erreur:
MsgBox Error,,"Fonction Toto"
'Resume Next
end function

Une fois que tu as repéré la fonction en cause, tu enlèves le ' devant
resume next, tu places un point d'arrêt et lorsque l'erreur se produit tu
tapes F8 et tu te trouves sous la ligne ayant causé l'erreur.
--
Cordialement

Aski

AntiSpamEdit (ASE) - XtractOE - Aide de K9 en français
http://h.charlier.de.chily.perso.cegetel.net/
ou
http://h.dechily.free.fr/
Avatar
Jean-Marc
"Aski" a écrit dans le message de
news:%
Ajoute une gestion d'erreur dans chaque procédure.

Private Function Toto as boolean
on error goto Erreur
...
'ton code
exit function

Erreur:
MsgBox Error,,"Fonction Toto"
'Resume Next
end function



Hello,

En plus de ce qu'a déjà expliqué Aski, voici quelques conseils
et détails:
- Toujours placer une gestion d'erreur, dans les fonctions comme
dans les Sub (à ce proposer, plutot utiliser uniquement des fonctions)
- Se servir du retour de la focntion comme indicateur de bon
fonctionnement (par ex TRUE=OK, FALSE=NOT OK, ou l'inverse)
- Toujours passer des paramètres additionnels à la fonction, qui
contiendront le code de l'erreur, la descrition de l'erreur et une
description détaillée, la plus précise possible.
- Toujours laisser à l APPELANT le soin de gérer l'erreur, pour une
simple raison: la fonction elle même ne peut en général pas faire
grand chose pour réparer, contrairement à l'appelant.

Sur cette base, voici un exemple de fonction et d'appel de celle ci
avec traitement de l'erreur:

' 8<----------------------------
Option Explicit

Private Sub Command1_Click()
Dim bRet As Boolean
Dim szErr As String
Dim szErrExtended As String
Dim lErr As Long
Dim param1 As Long
Dim param2 As Long

param1 = 23
param2 = 0
bRet = maFonction(param1, param2, szErrExtended, szErr, lErr)
If Not bRet Then
' une erreur s'est produite, on la traite
' pour l'exemple une simple message box:
MsgBox "Erreur : " & szErrExtended & vbCrLf & _
szErr & "(" & lErr & ")", vbExclamation, "exemple"
Else
' tout va bien on continue
End If
End Sub

'-------------------------------------------------------
' Procedure : maFonction
' DateTime : 4/02/2006 14:06
' Author : Jean-Marc
' Purpose : On place ici une description fonctionnelle,
' la signification des paramètres, etc.
'-------------------------------------------------------
'
Private Function maFonction(ByVal param1 As Long, _
ByVal param2 As Long, _
ByRef szErrExtended As String, _
ByRef szErr As String, _
ByRef lErr As Long) As Boolean
' Les déclarations locales
Dim test As Long
' la gestion d'erreur
On Error GoTo maFonction_ERR

' le code proprement dit
test = param1 / param2
maFonction = True ' tout est OK

' label de fin de fonction
maFonction_END:
Exit Function

maFonction_ERR:
' récupération de la descritpion et
' du numéro de l'erreur
szErr = Err.Description
lErr = Err.Number
szErrExtended = "Fonction maFonction(), valeur des paramètres:" &
vbCrLf & _
"param1=" & param1 & " param2=" & param2
maFonction = False ' NON OK
Resume maFonction_END
End Function

' 8<----------------------------

Ca fait beaucoup de code me direz vous? Oui, bien sur!
Dans un programme professionnel bien écrit, on compte
en moyenne:
- 1/6 code utile = 16%
- 1/3 gestion d'erreur = 34%
- 1/2 commentaires = 50%

Ce ne sont pas des chiffres sortis comme ça du chapeau. C'est le
reflet de stats faites sur des années sur de très nombreux programmes,
de toute taille et style, dans n'importe quel langage. On s'est apperçu
que les programmes qui ne respectent pas plus ou moins cette proportion
sont des nids à bugs, ou des trucs qui marchent mais si immondes que
personne ne veut les faire évoluer, de peur de tout casser. Les
programmes
"autistes" (pas commentés, gestion d'erreur inexistante) ont coûté et
coûtent
encore des sommes astronomiques à bien des sociétés.

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
X
Merci,

En fait j'ai trouvé l'erreur (une liste qui avait trop avalée), mais
j'ai mis longtemps, cernant par des messages dans une autre liste... Le
problème est que je suis sur un fichier de 1,8 Mo, et je le lis par octet,
alors c'est long en plus...

Je retiens ta méthode, je ne connaissais pas, en fait je ne me suis
jamais servi d'un debugeur, je cherches mes erreurs à la main si je puis
dire...

Bon, je vais étudier ta méthode, et la conserver, merci encore :o)

----------------

"Aski" a écrit dans le message de news:
%
Salutatoi X,

Tu as donc déclaré :

Bonjour,

J'ai :

6
dépassement de capacité
projet 1

Lol, dépassement de capacité de quoi, où, comment faire ???

Merci beaucoup, au revoir et à bientôt :o)



Ajoute une gestion d'erreur dans chaque procédure.

Private Function Toto as boolean
on error goto Erreur
...
'ton code
exit function

Erreur:
MsgBox Error,,"Fonction Toto"
'Resume Next
end function

Une fois que tu as repéré la fonction en cause, tu enlèves le ' devant
resume next, tu places un point d'arrêt et lorsque l'erreur se produit tu
tapes F8 et tu te trouves sous la ligne ayant causé l'erreur.
--
Cordialement

Aski

AntiSpamEdit (ASE) - XtractOE - Aide de K9 en français
http://h.charlier.de.chily.perso.cegetel.net/
ou
http://h.dechily.free.fr/







Avatar
Aski
Salutatoi X,

Tu as donc déclaré :

Merci,

En fait j'ai trouvé l'erreur (une liste qui avait trop avalée),
mais j'ai mis longtemps, cernant par des messages dans une autre
liste... Le problème est que je suis sur un fichier de 1,8 Mo, et je
le lis par octet, alors c'est long en plus...



As-tu essayé la fonction
Input(n, #1) apès un Seek
n étant le nombre de caractères lus et 1 étant le n° du fichier ouvert.
Un fichier de 1,8 Mo n'est pas très long à lire surtout su tu lis par groupe
de garactères
Avatar
X
Ah, mais j'utilise rarement les fonctions, en plus je les maîtrise très mal
(ceci expliquant cela)...

Là, ma procédure était assez grosse, avec plusieurs possibilité d'erreurs
(liste, combo, fichier), alors je n'ai pas mis de gestion pour cette raison,
car ensuite il faut piloter tout ça, ça hache le code, c'est bien dans des
petites procédure à (fonction) unique...

A part les points stratégiques, je ne découpe pas trop le code en procédures
trop petites, car c'est pire que les goto ensuite, il faut chercher partout
pour voir ce que fait le reste du code, je préfère même doubler 20 lignes de
code dans la même procédure, que de faire seulement 20 lignes mais dans une
autres procédure, plus ça se suit, plus c'est clair. Par exemple,
l'impression = 1 procédure, la modif = 1, la création = 1, etc... Y en a qui
vont dans chaque procédure sus-citée des autres procédure, par exemple pour
ouvrir le fichier, pour appeler une boîte de dialogue, enfin par habitude
personnelle je limite la découpe à outrance... Généralement une procédure
correspond à une fonctionnalité du programme, et elles se suivent dans
l'ordre logique (le load est en premier, le unload à la fin, la création est
avant l'impression, etc); de la logique quand même...
Même les pointeurs ils ne servent qu'une fois (fonctionnalité), ça évite en
cas d'erreur la reporter ailleurs...

Généralement j'évite d'avoir l'erreur, par exemple sur une liste je vais
mettre (si > 65.000 sort), de préférence à avoir l'erreur et ensuite à la
gérer...

Sinon, je gère les erreurs, mais quand je pense qu'il peut s'en produire
une, souvent sur les fichiers, car indépendant du programme (l'utilisateur
peut le manipuler extérieurement en cours d'exécution)...

Enfin bref, là c'était une liste trop pleine, (un truc con, mais c'est
toujours des trucs cons les erreurs), je ramais car c'était long (je lisais
un fichier par octet sur 1,8 Mo)... Et l'erreur évidemment se produisait
dans les 65.000...

In fine, dans les procédures, pour bien gérer, l'idéal est de mettre une
adresse de ligne aux endroits stratégiques dans une variable globale, et
ainsi évidemment ça devient plus facile ensuite, mais bon, ça c'est la
théorie parfaite, souvent on néglige de le faire, trop contraignant, et puis
quand ça arrive on regrette...

Merci.

-------------



"Jean-Marc" a écrit dans le message de news:
43e4ad6e$0$3804$
"Aski" a écrit dans le message de
news:%
Ajoute une gestion d'erreur dans chaque procédure.

Private Function Toto as boolean
on error goto Erreur
...
'ton code
exit function

Erreur:
MsgBox Error,,"Fonction Toto"
'Resume Next
end function



Hello,

En plus de ce qu'a déjà expliqué Aski, voici quelques conseils
et détails:
- Toujours placer une gestion d'erreur, dans les fonctions comme
dans les Sub (à ce proposer, plutot utiliser uniquement des fonctions)
- Se servir du retour de la focntion comme indicateur de bon
fonctionnement (par ex TRUE=OK, FALSE=NOT OK, ou l'inverse)
- Toujours passer des paramètres additionnels à la fonction, qui
contiendront le code de l'erreur, la descrition de l'erreur et une
description détaillée, la plus précise possible.
- Toujours laisser à l APPELANT le soin de gérer l'erreur, pour une
simple raison: la fonction elle même ne peut en général pas faire
grand chose pour réparer, contrairement à l'appelant.

Sur cette base, voici un exemple de fonction et d'appel de celle ci
avec traitement de l'erreur:

' 8<----------------------------
Option Explicit

Private Sub Command1_Click()
Dim bRet As Boolean
Dim szErr As String
Dim szErrExtended As String
Dim lErr As Long
Dim param1 As Long
Dim param2 As Long

param1 = 23
param2 = 0
bRet = maFonction(param1, param2, szErrExtended, szErr, lErr)
If Not bRet Then
' une erreur s'est produite, on la traite
' pour l'exemple une simple message box:
MsgBox "Erreur : " & szErrExtended & vbCrLf & _
szErr & "(" & lErr & ")", vbExclamation, "exemple"
Else
' tout va bien on continue
End If
End Sub

'-------------------------------------------------------
' Procedure : maFonction
' DateTime : 4/02/2006 14:06
' Author : Jean-Marc
' Purpose : On place ici une description fonctionnelle,
' la signification des paramètres, etc.
'-------------------------------------------------------
'
Private Function maFonction(ByVal param1 As Long, _
ByVal param2 As Long, _
ByRef szErrExtended As String, _
ByRef szErr As String, _
ByRef lErr As Long) As Boolean
' Les déclarations locales
Dim test As Long
' la gestion d'erreur
On Error GoTo maFonction_ERR

' le code proprement dit
test = param1 / param2
maFonction = True ' tout est OK

' label de fin de fonction
maFonction_END:
Exit Function

maFonction_ERR:
' récupération de la descritpion et
' du numéro de l'erreur
szErr = Err.Description
lErr = Err.Number
szErrExtended = "Fonction maFonction(), valeur des paramètres:" &
vbCrLf & _
"param1=" & param1 & " param2=" & param2
maFonction = False ' NON OK
Resume maFonction_END
End Function

' 8<----------------------------

Ca fait beaucoup de code me direz vous? Oui, bien sur!
Dans un programme professionnel bien écrit, on compte
en moyenne:
- 1/6 code utile = 16%
- 1/3 gestion d'erreur = 34%
- 1/2 commentaires = 50%

Ce ne sont pas des chiffres sortis comme ça du chapeau. C'est le
reflet de stats faites sur des années sur de très nombreux programmes,
de toute taille et style, dans n'importe quel langage. On s'est apperçu
que les programmes qui ne respectent pas plus ou moins cette proportion
sont des nids à bugs, ou des trucs qui marchent mais si immondes que
personne ne veut les faire évoluer, de peur de tout casser. Les
programmes
"autistes" (pas commentés, gestion d'erreur inexistante) ont coûté et
coûtent
encore des sommes astronomiques à bien des sociétés.

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;



Avatar
X
Non, je lis par octet, mais il faut faire d'autre choses durant la
lecture dans une boucle, tester, récupérer les infos recherchées, gérer la
barre de progression, etc... Tout ça, ça quadruple le temps de lecture
normal à cause de l'affichage surtout...
Mon traitement met environ 2 minutes pour:
1,8 Mo sur -> PC 64bits + 1,8 Ghz + 512 ram + WindowsXPf+sp2

Tiens, voila ma boucle, peut être améliorée un peu, mais bof, pas grand
chose...

For i = debutFic To f1
nouveau = Fix(pas * i)
If nouveau > ancien Then ' bar de progression
Shape2.Width = Fix(pas * i)
ancien = nouveau
End If
'
DoEvents
If varStop = True Then Exit For ' arrêt recherche
compareA = ""
compareN = ""
For j = i To (i + f2) ' lit de 3 à 8 octets suivant choix recherche
Get p2a, j, octetR
If typeR = "a" Then compareA = compareA & octetR
If typeR = "n" Then
asciiR = Asc(octetR)
compareN = compareN & Format(asciiR, "000")
End If
Next j
'
If typeR = "a" And compareA = fouine Then ' si trouvé recherche alpha
List1.AddItem i
m = i ' octet
k = m 128
l = m Mod 128
If l <> 0 Then k = k + 1 ' bloc
Form1.Combo1.AddItem k & ", " & m
Form1.Combo1.ListIndex = 0
Label9.Caption = List1.ListCount
If List1.ListCount > 31999 Then
MsgBox "Abandon de recherche (maxi 32.000) " & vbLf & "Mais
poursuite du traitement sur les occurences trouvées ", vbExclamation
Exit For
End If
If (i + f2) <= f1 Then i = i + 8
End If
' JE préfère doubler le code et 'lavoir sou l'oeil...
If typeR = "n" And compareN = fouine Then ' si trouvé, recherche
numérique
List1.AddItem i
m = i ' octet
k = m 128
l = m Mod 128
If l <> 0 Then k = k + 1 ' bloc
Form1.Combo1.AddItem k & ", " & m
Form1.Combo1.ListIndex = 0
Label9.Caption = List1.ListCount
If List1.ListCount > 31999 Then
MsgBox "Abandon de recherche (maxi 32.000) " & vbLf & "Mais
poursuite du traitement sur les occurences trouvées ", vbExclamation
Exit For
End If
If (i + lgr_cherche) <= f1 Then i = i + lgr_cherche
End If
Next i

------------

"Aski" a écrit dans le message de news:

Salutatoi X,

Tu as donc déclaré :

Merci,

En fait j'ai trouvé l'erreur (une liste qui avait trop avalée),
mais j'ai mis longtemps, cernant par des messages dans une autre
liste... Le problème est que je suis sur un fichier de 1,8 Mo, et je
le lis par octet, alors c'est long en plus...



As-tu essayé la fonction
Input(n, #1) apès un Seek
n étant le nombre de caractères lus et 1 étant le n° du fichier ouvert.
Un fichier de 1,8 Mo n'est pas très long à lire surtout su tu lis par
groupe de garactères



Avatar
parci
On Sat, 4 Feb 2006 14:34:37 +0100, "Jean-Marc"
wrote:

En plus de ce qu'a déjà expliqué Aski, voici quelques conseils
et détails:
- Toujours placer une gestion d'erreur, dans les fonctions comme
dans les Sub (à ce proposer, plutot utiliser uniquement des fonctions)
- Se servir du retour de la focntion comme indicateur de bon
fonctionnement (par ex TRUE=OK, FALSE=NOT OK, ou l'inverse)
- Toujours passer des paramètres additionnels à la fonction, qui
contiendront le code de l'erreur, la descrition de l'erreur et une
description détaillée, la plus précise possible.
- Toujours laisser à l APPELANT le soin de gérer l'erreur, pour une
simple raison: la fonction elle même ne peut en général pas faire
grand chose pour réparer, contrairement à l'appelant.



J'suis d'accord mais je me demande quand même pourquoi tu ne te sers
pas de l'objet Err pour remonter l'erreur à la source (tu peux
modifier Err.Source pour indiquer dans quelle procédure l'erreur a eu
lieu et remonter jusqu'à ta procédure principale à coup d'Err.Raise).
C'est un peu moins lourd que d'ajouter systématiquement 3 paramètres à
toutes fonctions. En prime, avec MZ-Tools, on peut implémenter ça
presque automatiquement.

Pour reprendre ton exemple, ça donnerait :

Private Sub Command1_Click()

Dim bRet As Boolean
Dim param1 As Long
Dim param2 As Long

On Error GoTo Command1_Click_ERR

param1 = 23
param2 = 0
bRet = maFonction(param1, param2)
If Not bRet Then
Exit Sub
End If

On Error GoTo 0
Exit Sub


Command1_Click_ERR:

MsgBox Err.Number & vbCrLf & Err.Description & vbCrLf & vbCrLf &
Err.Source, vbCritical, App.Title

End Sub

'-------------------------------------------------------
' Procedure : maFonction
' DateTime : 4/02/2006 14:06
' Author : Jean-Marc
' Purpose : On place ici une description fonctionnelle,
' la signification des paramètres, etc.
'-------------------------------------------------------
'
Private Function maFonction(ByVal param1 As Long, _
ByVal param2 As Long) As Boolean
' Les déclarations locales
Dim test As Long
' la gestion d'erreur
On Error GoTo maFonction_ERR

' le code proprement dit
test = param1 / param2
maFonction = True ' tout est OK

On Error GoTo 0
Exit Function


maFonction_ERR:

Err.Source = Err.Source & vbCrLf & Me.Name & ".maFonction"

Err.Raise Err.Number, Err.Source, Err.Description

End Function
Avatar
Jean-Marc
"parci" a écrit dans le message de
news:
On Sat, 4 Feb 2006 14:34:37 +0100, "Jean-Marc"
wrote:

J'suis d'accord mais je me demande quand même pourquoi tu ne te sers
pas de l'objet Err pour remonter l'erreur à la source (tu peux
modifier Err.Source pour indiquer dans quelle procédure l'erreur a eu
lieu et remonter jusqu'à ta procédure principale à coup d'Err.Raise).
C'est un peu moins lourd que d'ajouter systématiquement 3 paramètres à
toutes fonctions. En prime, avec MZ-Tools, on peut implémenter ça
presque automatiquement.



<snip le code>

Hello,

On peut (en principe) faire comme tu le dis. Je préfère ma méthode car
elle est transposable dans tous les langages de programmation (y
compris sans mécanisme de Err.Raise).

En passant des paramètres additionnels de façon systématique, on fait
des fonctions qui sont "self content": elles sont autonomes et ne
dépendent que d'elles mêmes.

Si demain j'implémente ma_fonction() en C, je n'ai qu'à transcrire
(traduire), sans me préoccuper de savoir quels mécanismes sont
derrière. Je fais confiance à l'appelant pour tester mes paramètres de
retour, etc.

Enfin, ce mécanisme général permet de remonter et de traiter des
erreurs venant de procédures très imbriquées. Dans tout un tas de
secteurs, un programme ne *DOIT* pas planter. Il peut avoir un
dysfonctionnement causé par tel ou tel évènement ou donnée erronée,
mais il de doit *JAMAIS* se planter lamentablement, au milieu de rien,
sans diagnostic hyper détaillée de l'erreur et de sa cause. Ce genre de
mécanisme est universellement employé dans de tels programmes, c'est la
garantie qu'aucune erreur inattendue ne puisse survenir. Pour les
auditeurs du code (ceux qui font l'audit de sécurité), il est facile de
lire un tel code car "il suffit" de vérifier que toutes les fonctions
ont le bon format, qu'elles remplissent convenablement les paramètres
et enfin (et surtout) que tous les appelants testent toujours les
retours de fonctions. En cas d'erreur, l'appelant peut soit traiter
l'erreur, ou si il ne sait pas, la remonter à son propre appelant (en
empilant si il le faut les paramètres des erreurs précédentes), et
ainsi de suite. A la fin, soit une des procédures sait faire quelque
chose, soit il s'est produit un truc grave ou impossible à résoudre et
le programme peut s'arréter de façon controlé, en exécutant son code
de secours, de nettoyage, etc., mais surtout en ayant la possibilité
d'écrire dans son fichier de log (ou tout autre dispositif) un rapport
d'erreur extrèmenet détaillé sur ce qui s'est passé.

Autant d'arguments qui font qu'il est plus *sain* de faire des
implémentations les moins dépendantes possibles de mécanismes liés au
langage ou à la plateforme. Les fonctions "auto-démerdantes" sont la
base de la programmation en milieu industriel et un principe
fondamental du génie logiciel.

Ce que tu qualifies de "lourd" (remonter 2 ou 3 params de plus à chaque
fonction) n'est qu'une habitude à prendre. A l'usage, les programmes
sont certes un peu plus longs, mais sont systématiques donc plus
faciles à lire, à maintenir, à mettre au point, etc.

Voila, désolé si j'ai été un peu long :-) C'est un sujet que je connais
très très bien (...) et je pourrais en discuter pendant des heures :-)

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Aski
Salutatoi Jean-Marc,

Tu as donc déclaré :

Voila, désolé si j'ai été un peu long :-) C'est un sujet que je
connais très très bien (...) et je pourrais en discuter pendant des
heures :-)



Merci professeur.
On tiendra compte de ta sage réflexion. ;-)
Merci
--
Aski