J'ai une grosse appli en VB6 ou certaines erreurs sont "normales"
function X1() as boolean
on error goto Erreur_X1
...
return true
exit function
Erreur_X1:
return false
end function
Là ou ca coince c'est bien sur quand une fonction de ce genre en appelle une
autre, car la déclaration d'un gestionnaire d'erreur écrase la précédente.
Donc je voudrais être capable, avant de faire un "on error goto" de
sauvegarder l'état du gestionnaire d'erreur (ce qu'il doit faire en cas
d'erreur) pour le restituer proprement si tout se passe bien dans la fonction
avant de ressortir.
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
Guy DETIENNE
Salut ;O)
Je sais qu'il existe On Local Error Goto .... sensé gérer les erreurs locales mais après lecture sur le net, il semblerait que cela ne soit pas du tout efficace. La clause Local serait un reliquat du vieux Quick Basic et Basic PDS pour satisfaire la compatibilité descendante. Mais il faudrait tester l'utilité d'une telle clause.
J'ai trouvé un fichier PDF (en anglais) où l'on parle entre autre d'une gestion efficace des erreurs et des erreurs locales. http://www.charteris.com/Publications/WhitePapers/Downloads/ErrorHandling.pdf Va directement sur la page 11.
Apparemment pour être efficace (et perso c'est ainsi que je procède), il faut insérer dans chaque procédure et fonction une gestion d'erreur et éventuellement utiliser Err.Clear pour réinitialiser l'objet Err pour ne pas 'tromper' les procédures appelantes en cas d'erreur dans des procédures appelées...
Voilà ce que je peux en dire... Bonne chance.
Guy
"patrick_de_toulouse" a écrit dans le message de news:
J'ai une grosse appli en VB6 ou certaines erreurs sont "normales"
function X1() as boolean on error goto Erreur_X1 ... return true exit function Erreur_X1: return false end function
Là ou ca coince c'est bien sur quand une fonction de ce genre en appelle une autre, car la déclaration d'un gestionnaire d'erreur écrase la précédente.
Donc je voudrais être capable, avant de faire un "on error goto" de sauvegarder l'état du gestionnaire d'erreur (ce qu'il doit faire en cas d'erreur) pour le restituer proprement si tout se passe bien dans la fonction avant de ressortir.
C'est possible ?
Salut ;O)
Je sais qu'il existe On Local Error Goto .... sensé gérer les erreurs
locales mais après lecture sur le net, il semblerait que cela ne soit pas du
tout efficace.
La clause Local serait un reliquat du vieux Quick Basic et Basic PDS pour
satisfaire la compatibilité descendante. Mais il faudrait tester l'utilité
d'une telle clause.
J'ai trouvé un fichier PDF (en anglais) où l'on parle entre autre d'une
gestion efficace des erreurs et des erreurs locales.
http://www.charteris.com/Publications/WhitePapers/Downloads/ErrorHandling.pdf
Va directement sur la page 11.
Apparemment pour être efficace (et perso c'est ainsi que je procède), il
faut insérer dans chaque procédure et fonction une gestion d'erreur et
éventuellement utiliser Err.Clear pour réinitialiser l'objet Err pour ne pas
'tromper' les procédures appelantes en cas d'erreur dans des procédures
appelées...
Voilà ce que je peux en dire...
Bonne chance.
Guy
"patrick_de_toulouse" <patrick_de_toulouse@discussions.microsoft.com> a
écrit dans le message de news:
C2E23DB8-31A2-41D8-82DD-ADB16C1A764E@microsoft.com...
J'ai une grosse appli en VB6 ou certaines erreurs sont "normales"
function X1() as boolean
on error goto Erreur_X1
...
return true
exit function
Erreur_X1:
return false
end function
Là ou ca coince c'est bien sur quand une fonction de ce genre en appelle
une
autre, car la déclaration d'un gestionnaire d'erreur écrase la précédente.
Donc je voudrais être capable, avant de faire un "on error goto" de
sauvegarder l'état du gestionnaire d'erreur (ce qu'il doit faire en cas
d'erreur) pour le restituer proprement si tout se passe bien dans la
fonction
avant de ressortir.
Je sais qu'il existe On Local Error Goto .... sensé gérer les erreurs locales mais après lecture sur le net, il semblerait que cela ne soit pas du tout efficace. La clause Local serait un reliquat du vieux Quick Basic et Basic PDS pour satisfaire la compatibilité descendante. Mais il faudrait tester l'utilité d'une telle clause.
J'ai trouvé un fichier PDF (en anglais) où l'on parle entre autre d'une gestion efficace des erreurs et des erreurs locales. http://www.charteris.com/Publications/WhitePapers/Downloads/ErrorHandling.pdf Va directement sur la page 11.
Apparemment pour être efficace (et perso c'est ainsi que je procède), il faut insérer dans chaque procédure et fonction une gestion d'erreur et éventuellement utiliser Err.Clear pour réinitialiser l'objet Err pour ne pas 'tromper' les procédures appelantes en cas d'erreur dans des procédures appelées...
Voilà ce que je peux en dire... Bonne chance.
Guy
"patrick_de_toulouse" a écrit dans le message de news:
J'ai une grosse appli en VB6 ou certaines erreurs sont "normales"
function X1() as boolean on error goto Erreur_X1 ... return true exit function Erreur_X1: return false end function
Là ou ca coince c'est bien sur quand une fonction de ce genre en appelle une autre, car la déclaration d'un gestionnaire d'erreur écrase la précédente.
Donc je voudrais être capable, avant de faire un "on error goto" de sauvegarder l'état du gestionnaire d'erreur (ce qu'il doit faire en cas d'erreur) pour le restituer proprement si tout se passe bien dans la fonction avant de ressortir.
C'est possible ?
patrick_de_toulouse
Merci Guy, c'est un bon article et à priori j'étais dans le faux.
Le gestionnaire d'erreurs de VB6 semble beaucoup plus robuste que je ne le craignais. En fait on peut très bien avoir un empillement de fonctions et chacune son gestionnaire d'erreur. Et quand il dépile les fonctions (quand on sort de l'une pour remonter dans l'autre) il dépile bien sagement et symétriquement les déclarations de gestionnaire d'erreur.
Et si à un niveau intermédiaire il n'y en a pas, il prend le premier de niveau supérieur ce qui est très bien (j'avais peur qu'il prenne le dernier déclaré quel que soit le niveau d'imbrication).
Bref à priori rien que du robuste ! (comme d'hab avec VB6 d'ailleurs)
Merci Guy, c'est un bon article et à priori j'étais dans le faux.
Le gestionnaire d'erreurs de VB6 semble beaucoup plus robuste que je ne le
craignais. En fait on peut très bien avoir un empillement de fonctions et
chacune son gestionnaire d'erreur. Et quand il dépile les fonctions (quand on
sort de l'une pour remonter dans l'autre) il dépile bien sagement et
symétriquement les déclarations de gestionnaire d'erreur.
Et si à un niveau intermédiaire il n'y en a pas, il prend le premier de
niveau supérieur ce qui est très bien (j'avais peur qu'il prenne le dernier
déclaré quel que soit le niveau d'imbrication).
Bref à priori rien que du robuste ! (comme d'hab avec VB6 d'ailleurs)
Merci Guy, c'est un bon article et à priori j'étais dans le faux.
Le gestionnaire d'erreurs de VB6 semble beaucoup plus robuste que je ne le craignais. En fait on peut très bien avoir un empillement de fonctions et chacune son gestionnaire d'erreur. Et quand il dépile les fonctions (quand on sort de l'une pour remonter dans l'autre) il dépile bien sagement et symétriquement les déclarations de gestionnaire d'erreur.
Et si à un niveau intermédiaire il n'y en a pas, il prend le premier de niveau supérieur ce qui est très bien (j'avais peur qu'il prenne le dernier déclaré quel que soit le niveau d'imbrication).
Bref à priori rien que du robuste ! (comme d'hab avec VB6 d'ailleurs)
