2009-09-04 4 views
1

J'utilise un gestionnaire d'erreur sur ma procédure d'appel principale et en laissant les autres procédures simplement rouler vers ce gestionnaire d'erreurs.propagation d'erreur VB6

Dois-je effacer l'erreur à chaque fois? Ou devrais-je quitter Sub au lieu de laisser le gestionnaire d'erreur continuer sur le sous-marin?

Je demande parce que j'ai lu que je peux attraper la première erreur, puis les autres erreurs ne seront pas traitées.

Désolé, ce n'est pas clair. Pas vraiment sûr de ce que je dis.

Merci!

Editer: Quelque chose comme ça. Est-ce nécessaire?

Public Sub SubA() 
On Error Goto ProcError 

    ' other code 
    MsgBox FuncA() 

ProcExit: 
    Exit Sub 

ProcError: 
    MsgBox Err.Description 
    Resume ProcExit 
End Sub 
+1

s'il vous plaît poster votre propre code (ou une partie de celui-ci au moins) qui démontre la question. – bugmagnet

+0

où effacez-vous l'erreur, selon l'exemple de code? – shahkalpesh

+0

Eh bien, j'ai lu que "Resume ProcExit" fait la même chose que Err.Clear. Mais pourquoi le code que j'ai posté comme ça? Pourquoi "Reprendre ProcExit"? Juste pour effacer l'erreur? Alors que la même procédure peut gérer l'erreur potentielle suivante? –

Répondre

2

OP: Dois-je effacer l'erreur à chaque fois? Ou devrais-je quitter Sub au lieu de laisser le gestionnaire d'erreur continuer sur le sous-marin? Que voulez-vous dire par effacer l'erreur?


Habituellement, la procédure est écrite de cette manière

public sub myProcedure() 
on error goto e: 
'statements that could raise error 
exit sub 

e: 
Log err.Number, err.Description, "error occurred in myProcedure" 
end sub 

OU

Vous pouvez choisir de ne pas ajouter le gestionnaire d'erreurs. Dans ce cas, l'erreur sera propagée à l'appelant (ou la procédure où il est géré).

Veuillez poster l'exemple de code de ce que vous essayez d'atteindre & votre attente.

EDIT: Voici ce que le code affiché par vous signifie

Public Sub SubA() 
On Error Goto ProcError 

    ' other code 
    MsgBox FuncA() 
exit sub 'put exit sub otherwise it will execute the line below, even if no error 

ProcExit: 
'this statement will get executed after the error msgbox is shown 
msgbox "Reached ProcExit" 
Exit Sub 

ProcError: 
MsgBox Err.Description 'catch the error and show the msgbox 
'error is cleared the point it reaches ProcError 
'Resume ProcExit acts as goto, to execute any statements after the error is handled 
Resume ProcExit 
End Sub 
+0

Voici un exemple Pas le mien Mais je veux savoir si c'est nécessaire pour faire cela pour effacer l'erreur, puis continuer à exécuter le programme Public Sub SubA() En cas d'erreur Goto ProcError 'autre code MsgBox FoncA() ProcExit: Exit Sub ProcError: MsgBox Err.Description CV ProcExit –

1

Avec votre exemple particulier, vous ne devez effacer les erreurs parce que votre modèle est basé sur la capture des erreurs. Bien qu'il ne fait pas mal:

ProcExit: 
    Exit Sub 

ProcError: 
    MsgBox Err.Description 
    Err.Clear 
    Resume ProcExit 

Maintenant, si vous aviez un modèle où vous la vérification des erreurs au lieu de les attraper, alors oui, vous auriez à effacer. Voici un petit exemple:

On Error Resume Next 
Dim o as Object 

Set o = myCollection(someKey) 

if Err.Number <> 0 then 
    ... respond to error 
    Err.Clear 

J'espère que cela aide.

1

L'objet Err est effacé chaque fois que vous quittez un sous-programme comme prévu (par exemple, aucune erreur ne se produit). Dans votre exemple, l'instruction Resume ProcExit est inutile. Les deux sous-marins suivants se comportent de la même façon:

Public Sub SubA() 
    On Error Goto ProcError 
    MsgBox FuncA() 
ProcExit: 
    Exit Sub 
ProcError: 
    MsgBox Err.Description 
    Resume ProcExit 
End Sub 

Public Sub SubA() 
    On Error Goto ProcError 
    MsgBox FuncA() 
    Exit Sub 
ProcError: 
    MsgBox Err.Description 
End Sub 

Vous ne devez pas utiliser l'instruction Exit Sub pour effacer l'objet Err. Tout simplement tomber du sous-marin lorsque vous frappez End Sub a le même effet. Si vous voulez que les erreurs "des autres procédures" à "roll up" (un meilleur mot est propagé) au gestionnaire d'erreurs de votre procédure d'appel principale, elles ne doivent pas contenir de gestionnaires d'erreurs. Par exemple, supposons que Main appelle SubA, et SubA appelle FuncA. Une erreur se produit dans FuncA.Si vous manipulez l'erreur dans FuncA en affichant simplement une boîte de message, comme vous le faites dans votre exemple, le code continuera à s'exécuter dans SubA, mais sera dans un état instable car quelque chose s'est mal passé dans FuncA et SubA ne sait rien il.

Une option consiste à ne pas placer de gestionnaires d'erreurs dans SubA et FuncA. Lorsqu'une erreur survient dans FuncA, elle est augmentée à SubA, qui la soulève à Main où elle est ensuite correctement gérée.

Une option encore meilleure est de piéger les erreurs, de les consigner, puis de les augmenter de nouveau. Ensuite, lorsque l'erreur arrive finalement à votre sous-main principal avec le gestionnaire d'erreur, vous aurez plus d'informations à travailler avec.