Je n'ai pas lu beaucoup à ce sujet, mais l'auteur du lien ci-dessous recommande d'utiliser "Bubble Up" pour centraliser la manipulation des erreurs dans VBA.
EXCEL Programmation Week-end Course Crash via Google Books
Mais je ne suis pas sûr de savoir pourquoi il recommande cela, et il n'explique pas vraiment.
Quelqu'un peut-il me dire pourquoi je devrais mettre une erreur d'erreur dans chaque procédure au lieu d'utiliser "Bubble Up"? Ou du moins, savez-vous pourquoi l'auteur dit non?
Merci.
5 Réponses :
Je vois au moins une raison dans son explication: parce que cela vous prive du bénéfice du CV (suivant).
De plus, vous ne saurez pas dans quel module l'erreur s'est produite.
Il vaut mieux ne pas utiliser la partie "Bubble-up" de la manutention des erreurs car les erreurs doivent être traitées et si elles sont connues de quoi faire, si une telle erreur se produit - est mieux connue de la procédure à suivre Que faire que la procédure d'appel .
A / 0 n'est pas 0! Vous venez d'avaler une erreur réelle et de retourner un mauvais résultat.
@jtolle: Je ne discute pas du résultat de la division ici. Ceci est juste pour donner un exemple de traitement des erreurs et spécifiquement, en manipulant l'erreur lorsqu'elle se produit.
Vous avez besoin d'un meilleur exemple alors. Cette erreur spécifique ne devrait pas être traitée de cette façon.
Je ne suis pas sûr de savoir quelle est la gestion des erreurs par défaut de VBA, mais depuis son Visual Basic for applications, et ces applications incluent des éléments tels que Excel et Word, je suppose qu'une boîte de dialogue apparaît qui ne sera pas utile à la utilisateur.
Je suppose que l'auteur a été mordu par code ne manipulant pas les erreurs, il recommande maintenant toutes les procédures de gérer les erreurs.
La réponse complète est que vous devez connaître toutes les erreurs pouvant survenir et avoir un code en place pour le gérer, que ce soit aussi bas que possible (où vous ne savez peut-être pas quoi faire), ou aussi élevé autant que possible (ce qui signifie moins d'effort de rédaction de code de traitement des erreurs, mais ne sachant pas pourquoi l'erreur est survenue), ou de manière stratégique (qui est juste dans les bons endroits où vous devriez pouvoir récupérer des erreurs les plus courantes) ou tout ce qui peut être partout (ce qui peut être juste trop d'effort de développement).
VBA Est-ce que permet aux erreurs de buller. Il y a des exceptions, mais en général, vous n'avez pas besoin d'avoir une manipulation erronée dans chaque méthode pour empêcher une pop-up de jarre dans l'application.
La réponse courte à votre première question est "vous ne devrait pas em> mettre un gestionnaire d'erreur dans chaque procédure". Mais généralement Certains routines em> ont besoin d'eux! dire que "chaque procédure doit avoir un gestionnaire d'erreur" est en général terrible conseil. Les défauts avec la manipulation des erreurs de VBA ont été beaucoup discutés ailleurs. Conceptuellement, ce n'est pas tout ce qui différent de la forme plus standard de traitement des exceptions trouvée dans d'autres langues. La plupart des meilleures pratiques de ces langues s'appliquent. Vous devez gérer des erreurs au niveau le plus bas où les manipuler a du sens. Parfois, ceci est dans la procédure dans laquelle l'erreur s'est produite, plusieurs fois non. P> Souvent, la chose la plus significative peut faire une routine interne lorsqu'une erreur se produit est simplement de laisser passer la pile afin que cela puisse atteindre le code afin qu'il puisse atteindre le code qui sait quoi faire avec ça. Cela dépend vraiment de la routine et de la manière dont il convient au reste du programme. P> Considérez ces exemples: P> Un gestionnaire dans une procédure d'appel gérera toutes les erreurs soulevées par les routines qu'elle appels. Donc, si une routine particulière n'a pas besoin d'un nettoyage, ne mettez aucun code de gestionnaire d'erreur là-bas: p> d'autre part, vous avez peut-être besoin de tâches de nettoyage, Dans ce cas, vous avez besoin d'un gestionnaire d'erreur. P> Sub Caller()
On Error GoTo HANDLER
ChildProc
On Error GoTo 0
Exit Sub
HANDLER:
Debug.Print Error, "Parent cleanup"
End Sub
Sub ChildProc()
'Pretend this routine gets ahold of some resource that must be cleaned up when it's done
call get_resources()
On Error GoTo HANDLER
Debug.Print 10 / 0 ' causes error
On Error GoTo 0
'Clean up once we're done
call release_resources()
Exit Sub
HANDLER:
Debug.Print Error, "Child cleanup"
'Clean up in case of an error
call release_resources()
'Raise another error if necessary to let callers know something went wrong
Err.Raise 10000, "ChildProc", Error
End Sub
Pour un exemple de non-VBA, voir: Stackoverflow.com/Questtions/2737328/...
Toute ressource couvrant "coup de pied" s'il vous plaît?
@Qhararr, voir cette réponse et les liens contenus dans ... Stackoverflow.com/a/4432413/58845
Je ne suis pas d'accord que la manipulation ne devrait se produire que dans la procédure où elle se produit. Il peut y avoir des tâches de nettoyage dans l'appelant et le SUB. En outre, un gestionnaire de la procédure de niveau supérieur traitera facilement toutes les erreurs de tous les sous-marins.
@johnywhy, je pense que nous sommes d'accord! C'est le point de ma réponse. L'OP demandait pourquoi ce livre a recommandé de mettre en place une manipulation des erreurs dans chaque procédure. Mon point de vue est que de tels conseils sont incorrects.
@jtolle Votre texte original n'était pas clair: "Vous ne devriez pas mettre un gestionnaire d'erreur dans chaque procédure". J'ai édité des exemples de clarté et ajouté.
@johnywhy, je pense que je vois ce que tu pensais que je pourrais avoir voulu dire. Merci pour les exemples. J'ai élargi certains certains parce que pour montrer plus clairement pourquoi vous voudrez peut-être ou non un gestionnaire d'erreur local.
@jtolle Dans le premier exemple, cela n'est pas clair: "quelque chose est arrivé" . Il serait plus clair et utile d'être spécifique: "une erreur" , pas "quelque chose" . Aussi cette partie est confuse: «cette procédure ou une procédure que celle-ci appelée» - c'est vrai avec les deux exemples, mais que vous ne mettez ce commentaire que dans un exemple, cela suggère qu'il ne tient que vrais cet exemple, qui est incorrect. Je n'inclurais pas version_resources () , nous ne savons pas ce que cela signifie, et maintenant un noob demandera "ce qui est version_Resources () "? Mieux vaut simplement mettre un commentaire "code de nettoyage enfant ici" , imo!
@jtolle je ne dirais pas "Il n'y a rien que cette routine ne puisse faire à leur sujet" , c'est inexact et déroutant. Un commentaire plus précis serait "pas de nettoyage nécessaire"
Ouais, mais que signifie "nettoyage"? Je pense que si vous fournissez un exemple spécifique, la distinction entre "nettoyage des besoins" et "n'a pas besoin de nettoyage" devrait être explicite. Si j'y pense, c'est probablement pourquoi je n'ai pas fourni d'exemple de code lorsqu'il y a répondu il y a 12 ans (!) Il y a des années. Les principes de traitement des exceptions sont assez simples, de même que la réponse principale à l'OP - ne mettez pas l'EH dans chaque routine! Mais les détails de la manière de gérer exactement quelles sont les situations très spécifiques à la routine ou à une application. Peut-être que c'est mieux si vous faites exactement l'exemple que vous souhaitez montrer une réponse séparée.
Mes 2 cents: Vous devez mettre des médicaments d'erreur sur toutes les procédures et événements publics. Cela signifie que la procédure au bas de la pile d'appels aura toujours un gestionnaire d'erreur. Ajoutez ensuite des gestionnaires d'erreur dans vos autres procédures car cela a du sens. Si une erreur survient dans une procédure qui n'a pas de gestionnaire d'erreur, elle "bulle" sur le gestionnaire d'erreur de niveau supérieur où elle sera enregistrée / affichée de manière professionnelle. Un scénario où vous pouvez ajouter un gestionnaire d'erreur à une procédure privée (niveau inférieur) est la suivante: Le code doit être rapide. Vous avez une condition rare qui peut être évitée, mais vous obligera à effectuer un test logique coûteux à l'intérieur d'une boucle (ou pire une boucle imbriquée). Vous pouvez effectuer le test logique dans le gestionnaire d'erreurs, et s'il est dit «événement rare», effectuez la correction et la reprise. Comme la condition est rare, vous verrez des gains de performance pour la plupart des conditions. Si le gestionnaire d'erreur ne peut pas comprendre et corriger le problème, reprochez l'erreur de la bulle sur la pile.
Évidemment, ce n'est qu'un seul scénario.
-1 S'il vous plaît n'utilisez pas d'URL raccourcies. Personne n'aime suivre les liens aveugles au travail. (+1 Disponible sur le lien direct.)
Cet auteur est totalement incorrect. Le bouillonnement est un outil puissant et essentiel dans la programmation VBA professionnelle (parlant de 25 ans VBA Pro).