De bonnes Habitudes Pour VBA Erreur de Manipulation

Quels sont les bons modèles pour la gestion des erreurs dans VBA?

En particulier, que dois-je faire dans cette situation:

... some code ...
... some code where an error might occur ...
... some code ...
... some other code where a different error might occur ...
... some other code ...
... some code that must always be run (like a finally block) ...

Je veux gérer à la fois les erreurs, et de reprendre l'exécution après le code où l'erreur peut se produire. Aussi, la enfin de code à la fin doit TOUJOURS exécuter de n'importe quelles exceptions sont levées plus tôt. Comment puis-je obtenir ce résultat?

InformationsquelleAutor jwoolard | 2009-06-24
  1. 98

    Erreur de Manipulation en VBA

    • On Error Goto ErrorHandlerLabel
    • Resume (Next | ErrorHandlerLabel)
    • On Error Goto 0 (désactive l'actuel gestionnaire d'erreur)
    • Err objet

    La Err propriétés de l'objet sont normalement remis à zéro ou une chaîne de longueur nulle dans la routine de gestion des erreurs, mais il peut également être fait explicitement avec Err.Clear.

    Des erreurs dans la routine de gestion des erreurs sont appelé à disparaître.

    La gamme 513-65535 est disponible pour les erreurs de l'utilisateur.
    Pour la classe personnalisée des erreurs, vous ajoutez vbObjectError pour le numéro d'erreur.
    Voir MS documentation sur Err.Soulever et la liste des numéros d'erreur.

    Pour ne pas mis en œuvre l'interface de membres dans un dérivés classe, vous devez utiliser la constante E_NOTIMPL = &H80004001.

    Option Explicit
Sub HandleError()
Dim a As Integer
On Error GoTo errMyErrorHandler
a = 7 / 0
On Error GoTo 0
Debug.Print "This line won't be executed."
DoCleanUp:
a = 0
Exit Sub
errMyErrorHandler:
MsgBox Err.Description, _
vbExclamation + vbOKCancel, _
"Error: " & CStr(Err.Number)
Resume DoCleanUp
End Sub
Sub RaiseAndHandleError()
On Error GoTo errMyErrorHandler
' The range 513-65535 is available for user errors.
' For class errors, you add vbObjectError to the error number.
Err.Raise vbObjectError + 513, "Module1::Test()", "My custom error."
On Error GoTo 0
Debug.Print "This line will be executed."
Exit Sub
errMyErrorHandler:
MsgBox Err.Description, _
vbExclamation + vbOKCancel, _
"Error: " & CStr(Err.Number)
Err.Clear
Resume Next
End Sub
Sub FailInErrorHandler()
Dim a As Integer
On Error GoTo errMyErrorHandler
a = 7 / 0
On Error GoTo 0
Debug.Print "This line won't be executed."
DoCleanUp:
a = 0
Exit Sub
errMyErrorHandler:
a = 7 / 0 ' <== Terminating error!
MsgBox Err.Description, _
vbExclamation + vbOKCancel, _
"Error: " & CStr(Err.Number)
Resume DoCleanUp
End Sub
Sub DontDoThis()
' Any error will go unnoticed!
On Error Resume Next
' Some complex code that fails here.
End Sub
Sub DoThisIfYouMust()
On Error Resume Next
' Some code that can fail but you don't care.
On Error GoTo 0
' More code here
End Sub
    • c'est bien beau, mais est-il un lieu où toutes les erreurs sont répertoriées pour que je puisse savoir si la mienne est préexistante ou si j'ai besoin de créer?
    • voici une liste des codes d'erreur support.microsoft.com/kb/146864
    • Comment le code ci-dessus doit être modifié afin de se connecter sur l'entrée et tous à la sortie de l'appelé code (procédure, fonction, méthode et ainsi de suite)?
    InformationsquelleAutor guillermooo
  2. 35

    Je voudrais aussi ajouter:

    • Le mondial Err objet est le plus proche que vous avez pour un objet d'exception
    • Vous pouvez effectivement "lever une exception" avec Err.Raise

    Et juste pour le fun:

    • On Error Resume Next est le diable incarné et à éviter, comme il en silence cache les erreurs
    • +1 pour avertir Sur Eror Resume Next. Probablement l'une des raisons pour lesquelles VB programmes sont généralement plein de bugs.
    • Pas vrai. Lorsqu'il est utilisé correctement on Error Resume Next est un équivalent de try/catch. Utilisation correcte nécessite juste de chèques ou d'épargne de l'état d'erreur après chaque ligne. Il est complexe de vérification des erreurs, beaucoup moins verbeux. CEPENDANT, ils sont mal utilisés, tous les ci-dessus s'applique.
    • Je pense que tout le monde serait d'accord que Sur d'Erreur est l'équivalent de Try/Catch oui... mais on Error Resume Next? Elle provoque les erreurs à disparaître - notamment ceux que nous n'avons jamais prévu. Il est préférable de laisser les erreurs de saigner de la tête de zéro pendant des semaines sur pourquoi quelque chose de bizarre qui se passe [ce qui m'est arrivé lors du débogage de quelqu'un d'autre code]. Je ne l'utilise que dans des circonstances très spéciales, serré de petites fonctions où une bizarrerie forces vous un code d'erreur (par exemple, cet élément existe dans une Collection).
    • Si vous mettez trop de code dans errMyErrorHandler: le risque d'une erreur qui se passe dans votre gestionnaire d'erreur qui crée une boucle sans fin. Si vous les mettez on Error Resume Next avant de traiter l'erreur dans errMyErrorHandler il réinitialise l'objet Err et vous perdez l'information d'erreur. - Je déplacer mon erreur de traitement pour un sous et passer le tre.num et description des paramètres afin que je puisse ensuite utiliser Sur Error Resume Next comme je l'ai réinitialiser tout comme screenupdating et le curseur etc et de montrer l'erreur en utilisant le param valeurs... Call mdl_val.usr_sub_handle_error(Err.Source, Err.Description)
    • "à éviter" n'est pas exactement. Il y a beaucoup de cas nécessitant On Error Resume Next. Le principe commun de ces cas est lorsque certains résultats sont retournés par la levée d'une exception. Le plus souvent de cas est l'accès à un Collection objet par la chaîne de clé: dans ce cas, l'appelant ne peut pas savoir si il y a un article avec cette clé dans la Collection objet.
    • yep, je ne l'admettent dans un des commentaires ci-dessus
    • Je sais que c'est 10 ans... mais vraiment, vous devez supprimer votre commentaire... ou au moins de le modifier. Vous êtes tout simplement faux. Ben est à droite.

    InformationsquelleAutor Joel Goodwin
  3. 18

    De sorte que vous pourriez faire quelque chose comme ce 

    Function Errorthingy(pParam)
On Error GoTo HandleErr
' your code here
ExitHere:
' your finally code
Exit Function
HandleErr:
Select Case Err.Number
' different error handling here'
Case Else
MsgBox "Error " & Err.Number & ": " & Err.Description, vbCritical, "ErrorThingy"
End Select
Resume ExitHere
End Function

    Si vous voulez faire cuire dans la coutume des exceptions. (par exemple, ceux qui violent les règles de gestion) l'exemple ci-dessus, mais utiliser la fonction goto pour modifier le débit de la méthode que nécessaire.

    • C'est à peu près la façon dont nous avons géré les erreurs dans une grande application VB6 retour dans les jours. Relativement bien fonctionné, et est facile à utiliser. Autant que je me souvienne, nous avons eu une erreur de manipulation de la classe qui a été appelée au lieu d'avoir le code d'erreur dans la fonction. De cette façon, il était beaucoup plus facile de changer le comportement ainsi.
    • Il est généralement une bonne idée de mettre "on Error GoTo 0" après le bloc de code où vous en avez besoin gestion des erreurs. En outre, toute erreur dans le code de gestion d'erreur est appelé à disparaître.
    • Aucune idée si c'est idiomatiques VBA, mais pour .NET devs, si vous renommez "HandleErr" à "Attraper" et "ExitHere" pour "Enfin" et plisser les yeux...
    • ensuite, vous pouvez facilement passer à côté du Resume ExitHere qui fait beaucoup de la différence entre les deux paradigmes.
    InformationsquelleAutor Johnno Nolan
  4. 11

    Voici mon standard de mise en œuvre. J'aime les étiquettes pour être auto-descriptif.

    Public Sub DoSomething()
On Error GoTo Catch ' Try
' normal code here
Exit Sub
Catch:
'error code: you can get the specific error by checking Err.Number
End Sub

    Ou, avec un Finally bloc:

    Public Sub DoSomething()
On Error GoTo Catch ' Try
' normal code here
GoTo Finally
Catch:
'error code
Finally:
'cleanup code
End Sub
    • Ce qui ne se passerait si une exception est levée après Finally:? Donc On Error GoTo 0 immédiatement après Finally: peut-être nécessaires pour fixer les indésirables de la récursivité.
    • Si il y a un message d'erreur après la Finally bloc, il suffit de lancer l'erreur. Il ne sera pas re-boucle de retour vers le Finally bloc. (Essayez, vous verrez.) Si vous souhaitez gérer une erreur après le bloc finally, vous aurez besoin d'ajouter un autre On Error GoTo, mais probablement avec un autre label, comme Catch2. Mais ici, nous avons commencer à faire une digression dans le Code Propre méthodologie --> propre méthode aurez seulement besoin d'un gestionnaire d'erreur (et doit encore avoir son propre méthode dédiée à l'erreur de capture.)
    • Je crois que ce qui se passe après Finally: dépend si vous entrez après avoir été détournées pour Catch: (alors oui il vient de jette)... ou pas! Et dans ce dernier cas, c'est à dire avoir traversé GoTo Finally aura la On Error GoTo Catch toujours en vigueur, de sorte que le contrôle est détournée vers Catch: (pourrait être une bonne chose), puis Finally: est entré de nouveau, probablement pas ce que vous attendiez en premier lieu.
    • Si vous ajoutez un autre On Error GoTo Catch2 dans Finally: code, il aura été efficace dans ce dernier cas, mais pas si vous êtes allé à travers Catch: avant, car il n'est pas On Error GoTo -1 ni aucune Resume; l'ajout de l'ancien nous amène si loin de régulier try catch finally que l'on pourrait envisager d'arrêter analogie douteuse avant ce point.
    • Oui! D'accord avec les deux, une grande observation et de clarification.
    InformationsquelleAutor LimaNightHawk
  5. 4

    Professionnel Excel De Développement a une assez bonne erreur de manipulation régime. Si vous allez passer du temps en VBA, c'est probablement la peine d'obtenir le livre. Il y a un certain nombre de domaines où VBA est ce qui manque et ce livre a de bonnes suggestions pour la gestion de ces zones.

    PED décrit deux méthodes de gestion des erreurs. La principale est un système où tous les point d'entrée des procédures sont des sous-procédures et toutes les autres procédures sont les fonctions qui retournent des valeurs Booléennes.

    Le point d'entrée de procédure d'utilisation Sur les déclarations d'Erreurs de capture des erreurs assez bien conçu. Le non-point d'entrée des procédures de retourner Vrai si il n'y avait pas les erreurs et les Faux si il y avait des erreurs. Non, point d'entrée de procédure d'utilisation en cas d'Erreur.

    Les deux types de procédures d'utilisation d'une centrale de traitement d'erreur de procédure pour garder de l'erreur dans l'état et à enregistrer l'erreur.

    InformationsquelleAutor Dick Kusleika
  6. 3

    J'utilise un morceau de code que j'ai développé moi-même et c'est assez bon pour mes codes:

    Au début de la fonction ou de les sous, je définir:

    On error Goto ErrorCatcher:

    et puis, je me charge du possible, les erreurs

    ErrorCatcher:
Select Case Err.Number
Case 0 'exit the code when no error was raised
On Error GoTo 0
Exit Function
Case 1 'Error on definition of object
'do stuff
Case... 'little description here
'do stuff
Case Else
Debug.Print "###ERROR"
Debug.Print "   • Number  :", Err.Number
Debug.Print "   • Descrip :", Err.Description
Debug.Print "   • Source  :", Err.Source
Debug.Print "   • HelpCont:", Err.HelpContext
Debug.Print "   • LastDLL :", Err.LastDllError
Stop
Err.Clear
Resume
End Select
    InformationsquelleAutor Thiago Cardoso
  7. 3

    Voici un bon modèle.

    Pour le débogage: Lorsqu'une erreur est déclenchée, appuyez sur Ctrl-Pause (ou Ctrl-Pause), faites glisser le marqueur de pause (ou quelque chose comme ça) jusqu'à la Reprise de la ligne, appuyez sur F8 et vous ferez étape à la ligne que "jeté" de l'erreur.

    La ExitHandler est votre "Enfin".

    Sablier d'être tué à chaque fois.
    Barre d'état du texte sera effacé à chaque fois.

    Public Sub ErrorHandlerExample()
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
On Error GoTo ErrHandler
Dim varRetVal As Variant
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset("SomeTable", dbOpenDynaset, dbSeeChanges + dbFailOnError)
Call DoCmd.Hourglass(True)
'Do something with the RecordSet and close it.
Call DoCmd.Hourglass(False)
ExitHandler:
Set rst = Nothing
Set dbs = Nothing
Exit Sub
ErrHandler:
Call DoCmd.Hourglass(False)
Call DoCmd.SetWarnings(True)
varRetVal = SysCmd(acSysCmdClearStatus)
Dim errX As DAO.Error
If Errors.Count > 1 Then
For Each errX In DAO.Errors
MsgBox "ODBC Error " & errX.Number & vbCrLf & errX.Description
Next errX
Else
MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
End If
Resume ExitHandler
Resume
End Sub
Select Case Err.Number
Case 3326 'This Recordset is not updateable
'Do something about it. Or not...
Case Else
MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
End Select

    Il a aussi des pièges pour les DAO et VBA erreurs. Vous pouvez mettre un Select case dans l'erreur VBA section si vous souhaitez piège pour certains Err numéros.

    Select Case Err.Number
Case 3326 'This Recordset is not updateable
'Do something about it. Or not...
Case Else
MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
End Select
    InformationsquelleAutor whistle britches
  8. 3

    Le code ci-dessous montre une alternative qui s'assure qu'il existe un seul point de sortie pour le sub/function.

    sub something()
on error goto errHandler
' start of code
....
....
'end of code
' 1. not needed but signals to any other developer that looks at this
' code that you are skipping over the error handler...
' see point 1...
err.clear
errHandler:
if err.number <> 0 then
' error handling code
end if
end sub
    InformationsquelleAutor nickD
  9. 3

    Également pertinentes pour la discussion est relativement inconnu, Erl fonction. Si vous avez numérique étiquettes à l'intérieur de votre code de procédure, par exemple,

    Sub AAA()
On Error Goto ErrorHandler
1000:
' code
1100:
' more code
1200:
' even more code that causes an error
1300:
' yet more code
9999: ' end of main part of procedure
ErrorHandler:
If Err.Number <> 0 Then
Debug.Print "Error: " + CStr(Err.Number), Err.Descrption, _
"Last Successful Line: " + CStr(Erl)
End If   
End Sub

    La Erl fonction renvoie le plus récemment rencontré numberic étiquette de ligne. Dans l'exemple ci-dessus, si une erreur d'exécution se produit après l'étiquette 1200: mais avant 1300:, le Erl fonction sera de retour 1200, puisque c'est le plus recenlty avec succès rencontré une étiquette de ligne. Je trouve que c'est une bonne pratique à mettre une étiquette de ligne immédiatement au-dessus de votre erreur du bloc de gestion. Je typcially utilisation 9999 pour indiquer que la partie principale de la procuedure courut à sa devrait conculsion.

    NOTES:

    • Ligne les étiquettes DOIVENT être des entiers positifs -- une étiquette comme MadeItHere: n'est pas recogonized par Erl.

    • Étiquettes de ligne sont totalement sans lien avec le réel numéros de ligne d'un VBIDE CodeModule. Vous pouvez utiliser tous les nombres positifs que vous voulez, dans n'importe quel ordre que vous voulez. Dans l'exemple ci-dessus, il y a seulement 25 lignes de code, mais la ligne numéro de l'étiquette commencer à 1000. Il n'y a pas de relation entre l'éditeur numéros de ligne et de la ligne numéro de l'étiquette utilisée avec Erl.

    • Ligne numéro de l'étiquette n'a pas besoin d'être dans un ordre particulier, même si elles ne sont pas dans l'ordre croissant, ordre de haut en bas, de l'efficacité et de prestations de Erl est fortement diminuée, mais Erl sera toujours en rapport le nombre correct.

    • Étiquettes de ligne sont spécifiques à la procédure dans laquelle ils apparaissent. Si la procédure ProcA appelle la procédure ProcB et une erreur se produit dans ProcB qui repasse le contrôle de ProcA, Erl (en ProcA) sera de retour plus récemment rencontrée ligne numéro de l'étiquette dans ProcA avant qu'il appelle ProcB. De l'intérieur ProcA, vous ne pouvez pas obtenir le label de la ligne de numéros qui apparaissent dans ProcB.

    Utilisation des soins lors de la mise en ligne nombre d'étiquettes à l'intérieur d'une boucle. Par exemple,

    For X = 1 To 100
500:
' some code that causes an error
600:
Next X

    Si le code à la suite de la ligne étiquette 500 mais avant 600 provoque une erreur, et cette erreur survient sur le 20e itération de la boucle, Erl sera de retour 500, même si 600 a été rencontrée avec succès dans le précédent 19 interaction de la boucle.

    Bon placement des étiquettes de ligne au sein de la procédure est critique à l'aide de la Erl fonction pour obtenir réellement de l'information significative.

    Il ya un certain nombre de gratuit utilitaires sur le net, qui permet d'insérer étiquette de ligne numérique dans une procédure automatiquement, donc vous devez fine des informations d'erreur pendant le développement et le débogage, puis retirez les étiquettes dès que le code va vivre.

    Si votre code affiche les informations d'erreur à l'utilisateur si une erreur inattendue se produit, pourvu que la valeur de Erl dans cette information peut rendre la recherche et la résolution du problème INFINIMENT plus simple que si la valeur de Erl n'est pas signalé.

    InformationsquelleAutor Chip Pearson
  10. 2

    Méfiez-vous de l'éléphant piège:

    Je n'ai vu aucune mention de cela dans cette discussion. [Access 2010]

    Comment ACCESS/VBA gère les erreurs dans les objets de la CLASSE est déterminée par une option configurable:

    VBA Éditeur de Code > Outils > Options > Général > Erreur de Piégeage:

    De bonnes Habitudes Pour VBA Erreur de Manipulation

    • C'est génial - merci
    InformationsquelleAutor JoeRobbins
  11. 2

    - Je trouver la suite à mieux travailler, appelé la centrale de traitement d'erreur d'approche.

    Avantages

    Vous disposez de 2 modes de fonctionnement de votre application: Debug et Production. Dans le Debug mode, le code s'arrête à chaque erreur inattendue et vous permettre de déboguer facilement en sautant à la ligne où elle s'est produite en appuyant sur F8 deux fois. Dans le Production mode, un véritable message d'erreur sera affiché à l'utilisateur.

    Vous pouvez jeter intentionnelle des erreurs de ce genre, qui va arrêter l'exécution du code avec un message à l'utilisateur:

    Err.Raise vbObjectError, gsNO_DEBUG, "Some meaningful error message to the user"
Err.Raise vbObjectError, gsUSER_MESSAGE, "Some meaningful non-error message to the user"
'Or to exit in the middle of a call stack without a message:
Err.Raise vbObjectError, gsSILENT

    Mise en œuvre

    Vous avez besoin de "wrap" toutes les sous-routines et fonctions avec un nombre significatif de code suivantes avec les en-têtes et pieds de page, en veillant à spécifier ehCallTypeEntryPoint dans tous vos points d'entrée. Remarque le msModule constante, ce qui doit être mis dans tous les modules.

    Option Explicit
Const msModule As String = "<Your Module Name>"
' This is an entry point 
Public Sub AnEntryPoint()
Const sSOURCE As String = "AnEntryPoint"
On Error GoTo ErrorHandler
'Your code
ErrorExit:
Exit Sub
ErrorHandler:
If CentralErrorHandler(Err, ThisWorkbook, msModule, sSOURCE, ehCallTypeEntryPoint) Then
Stop
Resume
Else
Resume ErrorExit
End If
End Sub
' This is any other subroutine or function that isn't an entry point
Sub AnyOtherSub()
Const sSOURCE As String = "AnyOtherSub"
On Error GoTo ErrorHandler
'Your code
ErrorExit:
Exit Sub
ErrorHandler:
If CentralErrorHandler(Err, ThisWorkbook, msModule, sSOURCE) Then
Stop
Resume
Else
Resume ErrorExit
End If
End Sub

    Le contenu de la centrale module de gestionnaire d'erreur est le suivant:

    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' Comments: Error handler code.
'
'           Run SetDebugMode True to use debug mode (Dev mode)
'           It will be False by default (Production mode)
'
' Author:   Igor Popov
' Date:     13 Feb 2014
' Licence:  MIT
'
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Option Explicit
Option Private Module
Private Const msModule As String = "MErrorHandler"
Public Const gsAPP_NAME As String = "<You Application Name>"
Public Const gsSILENT As String = "UserCancel"  'A silent error is when the user aborts an action, no message should be displayed
Public Const gsNO_DEBUG As String = "NoDebug"   'This type of error will display a specific message to the user in situation of an expected (provided-for) error.
Public Const gsUSER_MESSAGE As String = "UserMessage" 'Use this type of error to display an information message to the user
Private Const msDEBUG_MODE_COMPANY = "<Your Company>"
Private Const msDEBUG_MODE_SECTION = "<Your Team>"
Private Const msDEBUG_MODE_VALUE = "DEBUG_MODE"
Public Enum ECallType
ehCallTypeRegular = 0
ehCallTypeEntryPoint
End Enum
Public Function DebugMode() As Boolean
DebugMode = CBool(GetSetting(msDEBUG_MODE_COMPANY, msDEBUG_MODE_SECTION, msDEBUG_MODE_VALUE, 0))
End Function
Public Sub SetDebugMode(Optional bMode As Boolean = True)
SaveSetting msDEBUG_MODE_COMPANY, msDEBUG_MODE_SECTION, msDEBUG_MODE_VALUE, IIf(bMode, 1, 0)
End Sub
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' Comments: The central error handler for all functions
'           Displays errors to the user at the entry point level, or, if we're below the entry point, rethrows it upwards until the entry point is reached
'
'           Returns True to stop and debug unexpected errors in debug mode.
'
'           The function can be enhanced to log errors.
'
' Date          Developer           TDID    Comment
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' 13 Feb 2014   Igor Popov                  Created
Public Function CentralErrorHandler(ErrObj As ErrObject, Wbk As Workbook, ByVal sModule As String, ByVal sSOURCE As String, _
Optional enCallType As ECallType = ehCallTypeRegular, Optional ByVal bRethrowError As Boolean = True) As Boolean
Static ssModule As String, ssSource As String
If Len(ssModule) = 0 And Len(ssSource) = 0 Then
'Remember the module and the source of the first call to CentralErrorHandler
ssModule = sModule
ssSource = sSOURCE
End If
CentralErrorHandler = DebugMode And ErrObj.Source <> gsNO_DEBUG And ErrObj.Source <> gsUSER_MESSAGE And ErrObj.Source <> gsSILENT
If CentralErrorHandler Then
'If it's an unexpected error and we're going to stop in the debug mode, just write the error message to the immediate window for debugging
Debug.Print "#Err: " & Err.Description
ElseIf enCallType = ehCallTypeEntryPoint Then
'If we have reached the entry point and it's not a silent error, display the message to the user in an error box
If ErrObj.Source <> gsSILENT Then
Dim sMsg As String: sMsg = ErrObj.Description
If ErrObj.Source <> gsNO_DEBUG And ErrObj.Source <> gsUSER_MESSAGE Then sMsg = "Unexpected VBA error in workbook '" & Wbk.Name & "', module '" & ssModule & "', call '" & ssSource & "':" & vbCrLf & vbCrLf & sMsg
MsgBox sMsg, vbOKOnly + IIf(ErrObj.Source = gsUSER_MESSAGE, vbInformation, vbCritical), gsAPP_NAME
End If
ElseIf bRethrowError Then
'Rethrow the error to the next level up if bRethrowError is True (by Default).
'Otherwise, do nothing as the calling function must be having special logic for handling errors.
Err.Raise ErrObj.Number, ErrObj.Source, ErrObj.Description
End If
End Function

    Pour définir vous-même dans le Debug mode, exécutez la commande suivante dans la fenêtre exécution:

    SetDebugMode True
    InformationsquelleAutor igorsp7
  12. 1

    Mon point de vue personnel sur une déclaration faite plus tôt dans ce thread:

    Et juste pour le fun:

    On Error Resume Next est le diable incarné et à éviter, comme il en silence cache erreurs.

    Je suis en utilisant le On Error Resume Next sur les procédures où je ne veux pas une erreur d'arrêter mon travail et où tout énoncé ne dépend pas de la suite des déclarations antérieures.

    Quand je fais cela j'ai ajouter une variable globale debugModeOn et je l'ai mis à True. Puis-je l'utiliser de cette façon:

    If not debugModeOn Then On Error Resume Next

    Quand je livrer mon travail, j'ai mis la variable à false, et donc de cacher les erreurs de l'utilisateur et de leur montrer pendant le test.

    Également l'utiliser pour faire quelque chose qui peut échouer comme l'appel de la DataBodyRange d'un ListObject qui peut être vide:

    On Error Resume Next
Sheet1.ListObjects(1).DataBodyRange.Delete
On Error Goto 0

    Au lieu de:

    If Sheet1.ListObjects(1).ListRows.Count > 0 Then 
Sheet1.ListObjects(1).DataBodyRange.Delete
End If

    Ou la vérification de l'existence d'un élément dans une collection:

    On Error Resume Next
Err.Clear
Set auxiliarVar = collection(key)
' Check existence (if you try to retrieve a nonexistant key you get error number 5)
exists = (Err.Number <> 5)
    • >If not debugModeOn Then On Error Resume Next Dans ce cas, il est préférable d'utiliser la compilation conditionnelle comme #If Hide_Errors > 0 Then On Error Resume Next et définir Hide_Errors dans le projet VBA propriétés Conditional Complication Arguments en conséquence.
    InformationsquelleAutor Jordi