Discussion :

[Igloobel]

Suite à cette discussion : goto qui ne marche pas indéfiniment

Débattons ici de la gestion d'erreur VBA.

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


Bonjour,
et à tous bonne année (vu que je l'ai pas dis à tous individuellement )

les amis je pense que l'on ségare le problème viens du GOTO !!!

Algorithmiquement c'est une horreur !! Il est en train de tricotter un gros sac de noeuds dont la maintenance ne sera pas difficile mais impossible donc dès qu'il y aura un changement ça sera GOTO poubelle !!!

moi je gérerai l'erreur plutôt que de passer par un goto étiquette de m.....

voici mon exemple à partir du sien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sub Tesssst()
    Dim i As Variant
 
    For i = 0 To 1
 
    Next i
     'On Error GoTo err
     i = "a"
 
    If Not IsNumeric(i) Then
       'message d'erreur comme quoi c'est pas numérique
        MsgBox "i = " & i & vbCrLf & "et n'est plus numérique"
    End If
End Sub

Il vaut mieux gérer l'erreur que de tenter de faire un goto quelque chose avec toutes les chances d'oublier de gérer ladite erreur

c'est à mon avis pas propre et pas Pro



Quand j'ai appris à programmer (en COBOL) ma Prof d'algo de l'époque nous avais dit si vous mettez un Goto c'est Goto -15 points sur la copie (sur 20)
Je peux vous garantir nous avons tous jamais mis un goto

et durant toute ma carrière (cela fait plus de 20 ans que je progamme) j'en ai pas mis non plus mais par contre j'ai souvent utilisé des procédures externes pour gérer les erreurs, j'ai jamais eu de problème et aucun Boss n'a ma fait de remarque à ce sujet.

Tout ça pour dire que si un numérique devient Alpha c'est un problème d'algo et pas de programmation !

C'est vrai que j'ai été "formater" contre le goto y compris les "On erreur Goto ..." même si c'est simple à gérer, mais on peut faire autrement la preuve ci-dessus.

donc au final
. si c'est pour voir comment on peut gérer une erreur pour la traiter à la fin, c'est une mauvaise idée mieux vaut externaliser la gestion de l'erreur
. si c'est pour voir comment cela gigotte je suis très tenter de dire "Oublies et concentre toi sur les erreurs d'algo qui sont légions"

Voilà je me suis un peu laché et si j'ai choqué des personnes j'en suis désolé, mon intention est juste de faire évolué le sujet

Une critique doit être constructive
et une critique constructive est toujours bonne à prendre

enfin c'est mon avis

bonne soirée à tous

[unparia]

Salut Igloobel
Je suis assez content de voir que tu as fait la même erreur que moi quant à la démarche du demandeur ...
Son i = "a" est justement pour provoquer une erreur et voir comment elle est gérée
Nous sommes deux endormis, toi et moi.

[Menhir]

GOTO poubelle !!!

La dernière fois que j'ai mis un GOTO dans un code, c'était avec du GW-Basic dans les années 80.
Depuis que j'ai gouté aux langages structurés (dont VBA fait partie), je n'ai plus jamais eu besoin de cette horreur.

moi je gérerai l'erreur plutôt que de passer par un goto étiquette de m.....

Il vaut mieux gérer l'erreur que de tenter de faire un goto quelque chose avec toutes les chances d'oublier de gérer ladite erreur[/U]
c'est à mon avis pas propre et pas Pro

re

C'est vrai que j'ai été "formater" contre le goto y compris les "On erreur Goto ..." même si c'est simple à gérer, mais on peut faire autrement la preuve ci-dessus.

C'est comme le côté obscure de la forme : plus facile, plus rapide, plus séduisant pour le padawan...

[unparia]

L'aide interne VBA me parait suffisamment claire à ce sujet --->>

GoTo, instruction
Voir aussi Exemple Particularités

Effectue un branchement inconditionnel vers une ligne déterminée d'une procédure.

Syntaxe

GoTo line

L'argument line peut contenir une étiquette de ligne ou un numéro de ligne quelconque.

Remarques

L'instruction GoTo ne peut effectuer un branchement que vers des lignes qui appartiennent à la procédure dans laquelle elle est utilisée.

Note Les programmes qui contiennent un trop grand nombre d'instructions GoTo peuvent s'avérer difficiles à lire et à corriger. Dans la mesure du possible, optez pour des instructions de contrôle structurées (Do...Loop, For...Next, If...Then...Else, Select Case).

[Arkham46]

Bonjour,

Je suis moins extrême.

Je suis tout à fait d'accord sur le fait qu'on ne laisse pas une erreur survenir si on peut la capturer en amont.

Mais un On Error Goto n'est qu'une manière d'écrire une gestion d'erreur, comme on utilise Try..Catch dans d'autres langages.

Sinon que se passe-t'il en cas d'erreur non prévue ?
L'utilisateur passe en débogage ? Ou on laisse l'appli crasher en runtime ?
On a tout de même besoin de gestion d'erreur, et tant pis si Microsoft a écrit le mot "Goto" dans l'instruction.
Il faut bannir Goto seul, mais il ne faut pas bannir On Error Goto ; il faut juste bien l'utiliser.

Ici on ne comprend pas bien le fond du problème.
Est-ce que l'utilisateur saisi quelque chose et on souhaite boucler tant que ce n'est pas un entier ?
Dans ce cas on n'utilise pas la gestion d'erreur pour revenir au début du code.
Sinon il faudrait un On Error Goto -1 pour "sortir" de la gestion d'erreur et permettre à VBA de capturer à nouveau une erreur.

[unparia]

Le demandeur est tout simplement en train de s'exercer (des petits exercices) au maniement de la gestion d'erreurs. Ce que n'avais pas compris d'emblée.
Il est vrai que l'exercice choisi (une erreur en boucle) est assez inattendu (on voit mal dans quelle circonstances on s'amuserait à reprendre en boucle la même erreur), mais c'est ce à quoi il s'exerce ...

[Pierre Fauconnier]

Salut.

Il ne faut pas confondre GOTO et ON ERROR GOTO qui, comme le dit Arkham, n'est jamais que la manière VBA de créer des TRY...CATCH... FINALLY présents dans d'autres langages. Et s'il faut bannir les GOTO, il ne faut surtout pas bannir les ON ERROR GOTO mais, à nouveau comme le dit Arkham, les utiliser à bon escient.

Cela dit, il ne faut pour moi jamais "programmer par l'erreur". Cela veut dire que l'on n'utilise pas les ON ERROR (quoi qu'on mette derrière) si on sait prévoir l'erreur. On réalise alors les tests en amont pour qu'il n'y ait pas de survenance de l'erreur. Par exemple, ça n'a pas de sens de gérer une division par zéro avec un gestionnaire d'erreur. Ca n'a pas plus de sens de gérer l'inexistence d'une feuille ou un dépassement des limites d'une feuille par le gestionnaire d'erreur, car ce sont des cas que le programmeur doit anticiper et gérer dans son code.

Les ON ERROR ne sont là que pour les erreurs que le code ne sait pas anticiper, ce qui réduit considérablement les cas d'utilisation. Il faut noter qu'en termes de gestion du processeur, les ON ERROR ne sont pas anodins et provoquent une rupture du thread avec redirection sur le processeur d'erreurs.

Quoi qu'il en soit, il faudrait à mon avis mettre une gestion d'erreur dans les procédures initiées par l'utilisateur, qui seront donc tout en bas de la pile d'appel, de manière à ne pas entrer en débogage ou planter l'appli (en tout cas pour des applis utilisées par des personnes qui ne doivent pas avoir accès au code...).

J'en profite pour montrer ce qu'il ne faut pas faire (à mon sens) puis ce que je préfère que l'on fasse (ne serait-ce que pour permettre UN Finally dans la gestion d'erreur).

A ne pas faire car on se prive de la possibilité d'un Finally et en plus, on crée deux sorties de proc alors que les règles de bonne programmation nous apprennent qu'il faut une seule sortie de procédure.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
sub ...()
on error goto endhandler
 
...
...
exit sub
endhandler:
...
...
end sub

A préférer car on a alors une possibilité de Finally juste après le endhandler

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
sub...()
on error goto endhandler
...
...
endhandler:
...
...
if err <>0 then
...
...
end if
end sub

Ou bien encore, si on veut la gestion d'erreur avant le Finally qui survient alors après le End If de la gestion d'erreurs (c'est le "vrai" Finally des autres langages, d'ailleurs)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
sub...()
on error goto endhandler
...
...
endhandler:
if err <>0 then
...
...
end if
...
...
end sub

[Menhir]

Mais un On Error Goto n'est qu'une manière d'écrire une gestion d'erreur, comme on utilise Try..Catch dans d'autres langages.

A condition de limiter l'effet de cette instruction à une ligne de code pour cibler très précisément cette instruction et de l'annuler par un On Error Goto 0 juste après.
C'est là seule façon d'avoir une idée à peu près précise de l'erreur qu'on gère.
Et ne le faire qu'après avoir explorer les autres possibilités de gérer cette erreur possible.

Sinon que se passe-t'il en cas d'erreur non prévue ? L'utilisateur passe en débogage ?

Et que va faire de plus le On Error Goto ?
A part afficher un message différent et qui sera moins expressif pour corriger l'erreur ?

A moins que l'erreur soit prévue et puisse être contournée pour permettre la continuation du programme.
Mais pour ça, comme je le disais, il faut limiter la zone d'effet du On Error à une instruction.

Certains développeurs s'en servent aussi pour donner l'illusion aux utilisateurs qu'ils ont la maitrise de leur code et ne pas assumer leur "imperfection".
Il est plus productif d'accepter qu'on puisse ne pas avoir tout prévu et, quand le problème survient, avoir les éléments pour le corriger au plus vite et améliorer le code.

[unparia]

Les développeurs consciencieux savent de surcroît assortir leur application d'un fichier .log où sont enregistrées les erreurs et leurs causes.
Ils le consultent de temps à autre, ce qui leur permet de déceler leurs propres erreurs éventuelles, mais également et surtout les garde-fous à mettre en place pour pallier des actions non prévues de l'utilisateur.

[Arkham46]

Et que va faire de plus le On Error Goto ?
A part afficher un message différent et qui sera moins expressif pour corriger l'erreur ?

Il va éviter que l'application crash en mode runtime par exemple.
Le message ce n'est pas compliqué, on a toutes les infos pour en générer un.
On peut ajouter le nom de la procédure où il y a l'erreur par exemple, c'est mieux que d'avoir un utilisateur qui appelle en disant qu'Access se ferme mais on ne sait pas où.
On peut également ajouter des numéros de ligne et connaître la ligne en erreur.
Il y a tout ce qu'il faut pour faire quelque chose de propre.

VBA n'est pas différent.
Toute gestion d'erreur se doit d'être intelligemment construite, quelque soit le langage.

[Menhir]

A moins que je me trompe (ce qui est très possible), je ne pense pas qu'en VBA il soit possible de récupérer la ligne de code ayant généré une erreur (je ne vois pas de propriété dans l'objet Err qui fournisse cette information).
Pour moi, en ce qui concerne Excel, faire un On Error Goto qui se contente d'envoyer un message en cas d'erreur, ça n'a pas d'intérêt. Parce qu'il ne fait rien de plus que ce que propose un message d'erreur classique et supprime de nombreux éléments permettant de rapidement corriger l'erreur, entre autre la désignation de la ligne incriminée et la possibilité de consulter le contenu des variables.

Pour moi, la gestion d'erreur n'a d'intérêt que si elle a une réelle action pour gérer l'erreur, soit qu'elle permette de la contourner ou de la réparer, soit qu'elle "nettoie" pour une fermeture propre (fermeture de fichier, coupure de liaisons, etc.) pour éviter qu'un simple plantage laisse un état instable.

[pijaku]

Bonjour Menhir,

A priori, tu ne connais pas la fonction Erl() :
https://silkyroad.developpez.com/VBA...rreurs/#LIII-C

[Invité]

bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Sub test()
On Error GoTo Erreur
For i = 0 To 10
    err.Raise 1164, "Test", "Viens boire une bière à ma santé !"
Next
Erreur:
If err <> 0 Then
    MsgBox err.Number & vbCrLf & err.Description
    err.Clear
    Resume Next
End If
End Sub

[Arkham46]

entre autre la désignation de la ligne incriminée et la possibilité de consulter le contenu des variables.

Mes utilisateurs ne débugent pas VBA.
Et encore une fois, en runtime ce n'est pas possible.
Le développeur peut désactiver la gestion d'erreur le temps de déboguer. C'est son boulot, pas celui de l'utilisateur.

[Pierre Fauconnier]

[...]
Pour moi, la gestion d'erreur n'a d'intérêt que si elle a une réelle action pour gérer l'erreur, soit qu'elle permette de la contourner ou de la réparer, soit qu'elle "nettoie" pour une fermeture propre (fermeture de fichier, coupure de liaisons, etc.) pour éviter qu'un simple plantage laisse un état instable.

Ce n'est que dans ce contexte que j'envisage une gestion d'erreur (écriture du log, fermeture propre, remise des options modifiées durant le traitement style DisplayAlerts ou EnableEvents,...).

Pour le numéro de ligne, SI tu as numéroté tes lignes, tu as la fonction ERL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Sub WriteLog(Message As String)
  Dim Channel As Long
 
  Channel = FreeFile
  Open ThisWorkbook.Path & "\trace.log" For Append As #Channel
  Print #Channel, Format(Now, "yyyy-mm-ddThh:mm:ss") & " : " & Message
  Close #Channel
End Sub
 
 
Sub Test4()
1 Dim a As Integer
2
3 On Error GoTo endhandler
4 a = "a"
5
6 endhandler:
7 If Err <> 0 Then WriteLog Err.Number & " on line " & Erl() & " : " & Err.Description
End Sub

EDIT: J'ajoute que tu peux évidemment personnaliser le message que tu envoies au log et donc être plus précis et plus circonstancié que le message lié à l'erreur survenue

[Menhir]

Pour le numéro de ligne, SI tu as numéroté tes lignes, tu as la fonction ERL

Des lignes numérotées dans un code en Basic ??? Wao, ça m'a replongé dans les années 80 et le GW-Basic dont je parlais précédemment.

[Pierre Fauconnier]

[...]
et supprime de nombreux éléments permettant de rapidement corriger l'erreur, entre autre la désignation de la ligne incriminée et la possibilité de consulter le contenu des variables[...]

Si le projet VBA est verrouillé pour l'affichage (ce qui est la moindre des choses si c'est quelqu'un d'autre qui utilise ton appli), ne pas gérer l'erreur va planter l'appli, sans aucune possibilité d'aller voir à l'intérieur ce qui s'y passe. Et je rejoins Arkham dans l'idée que l'utilisateur n'a pas à fourrer son nez dans le code et encore moins à essayer de déboguer. La gestion d'erreur va justement permettre de circonstancier l'erreur par un log détaillé qui va renseigner le programmeur sur ce qui s'est passé (s'il a bien conçu ses logs). Lui pourra, en modifiant l'option d'arrêt sur erreurs de son VBE, faire tourner le code pour qu'il s'arrête sur la ligne litigieuse et voir ce qui s'est passé. (je rappelle que placer l'option sur "arrêt sur toutes les erreurs" inhibe les ON ERROR...)

Pour la numérotation des lignes, il y a des compléments qui s'en chargent. Perso, je ne numérote pas mes lignes, mais je gère mes erreurs avec des logs, soit dans un fichier log à part (cas illustré dans le code que je viens de fournir), soit dans une feuille XL veryhidden. Pour Access, c'est soit dans un log soit dans une table.

J'ajoute que l'inscription dans un log n'est pas uniquement utile en cas d'erreur. Elle peut simplement tracer l'exécution, bonne ou mauvaise, d'un programme, et je conclurai en redisant ce que j'ai dit précédemment: Il faut prévoir les erreurs prévisibles (et éventuellement les "loguer") et gérer celles qui ne le sont pas (et éventuellement les "loguer")

[Arkham46]

Suite à cette discussion : goto qui ne marche pas indéfiniment

Débattons ici de la gestion d'erreur VBA pour ne pas polluer la discussion initiale.
Merci.

[Igloobel]

Bonjour,

Bon j'avoue que le coup du ERL avec la numérotaion des lignes je connaissais pas ...

je vais faire comme pijaku la dis consulter d'un peu plus près le tuto de silkyroad

par contre dès que j'ai des applis assez conséquentes à faire la gestion des erreurs seras, pour moi en tout cas, toujours une priorité avec des messages le plus explicite possible.

la gestion des logs comme le presente Pierre Fauconnier je l'avais mis en place pour le deboguage (surtout dans d'autres langage) et suprimé en suite par crainte d'une lenteur

il est peut-être utile de les laisser pour voir le bon (ou mauvais) déroulement du programme comme le dis Pierre Fauconnier.

[Pierre Fauconnier]

Cela étant, si le sujet du débat est la façon de gérer les erreurs, Alors ok, ça a du sens de débattre. Mais si le débat porte sur "vaut-il mieux ON ERROR RESUME [NEXT] que ON ERROR GOTO LABEL parce que GOTO c'est le mal", alors il est inutile.

Car désolé de décevoir ceux qui n'aiment pas le GOTO et gèrent les erreurs à coup de RESUME [NEXT], mais ce sont les "Monsieur Jourdain" de la gestion d'erreur, car RESUME [NEXT] et GOTO, c'est du pareil au même. Les développeurs du VB ont appelé ça RESUME [NEXT], mais ils auraient tout aussi bien pu appeler ça GOTO SELF et GOTO NEXT, par exemple. Le résultat aurait été strictement identique.

D'ailleurs, les langages qui modélisent les blocs TRY...CATCH...[FINALLY] n'ont pas mis en place de RESUME [NEXT], seul les branchements sur les [catch] et [FINALLY] ont été mis en place (branchement TRY...[CATCH]...[FINALLY] que l'on peut modéliser en VBA, je le rappelle), sauf bien sûr si on crée un bloc TRY d'une ligne qui "modélise" le RESUME NEXT. (Mais le sujet n'est pas Try...[Catch]...[Finally]... )

Conclusion: Quand on "fait" du RESUME [NEXT], on fait du GOTO, même si on n'aime pas ça