Bonjour.
Je pense que si tu veux le erl dans une procédure appellée il faut mettre ta gestion d'erreur dans la procédure appellée.
Si tu veux tout de même passé l'erreur à l'appellant tu peux mettre dans l'appellé un truc du genre :
1 2
| call msgbox("Erreur : " & err.number & ", " & err.description, vbExclamation) 'ici à la place tu peux mettre du code qui enregistre l'erreur dans une table ou un fichier ou autre endroit.
call err.raise(err.number, ,err.description) 'Passe l'erreur au niveau du dessus. |
Dans l'appelant tu peux aller "pécher" l'info sur l'erreur là où tu l'as stockée.
Et attention avec erl, perso j'ai eu des surprises sur le numéro de ligne retourné. Fait des tests pour valider que tu attrapes bien ce que tu veux.
Note en passant cela fait quelques siècles maintenant :-) qu'on ne numérote plus les lignes de code sauf très rares exceptions mais si tu le fais à la main pense à ne pas mettre des numéros contigus (ex 10, 11, 12) mais laisse des trous (ex : 10, 20, 30) comme cela tu n'as pas à renuméroter tes lignes à chaque insertion.
Une façon que j'ai découvert récement de savoir où cela plante est de mettre dans le code de la gestion d'erreur un truc du genre :
1 2 3
| call msgbox("Erreur : " & err.number & ", " & err.description, vbExclamation)
resume exit_ma_syb
resume |
Le second resume te sert quand tu as une erreur.
- Le message s'affiche
- tu fais [ctrl][break] pour arrêter l'exécution
- tu déplaces le curseur d'exécution sur le [CODEinline]resume[/CODEline]
- tu appuis sur [F8] et cela te ramène à l'instruction qui a provoquer l'erreur.
Une autre méthode que j'utilisais était de conditionner mes On Error Goto avec une constante globale :
cosnt IS_MODE_BEDUG as boolean = True 'False en prod
1 2 3
| if not IS_MODE_BEDUG then
on error goto Err_MaSub
end if |
Et la dernière stratégie est de prévenir l'erreur, si tu sais que tu vas avoir une erreur met du code avant pour faire une validation et ne pas exécuter le code concerné si tu es dans les conditions de l'erreur.
A+
Partager