PowerBuilder à Donf ! / [RESOLU] Nom de l'event/fonction courante et messages d'erreur

rincevent · 11-04-2013 11:01:11

Bonjour,

je souhaiterai développer une fct° qui me servira&it de message d'erreur générique.

je veux donc que le maximum d'information soit obtenues de manière dynamique par cette fonction, afin d'en simplifier l'utilisation / l'appel.

Par exemple je souhaite afficher le nom de l'objet d'où viens l'erreur et bien pour cela je passe un argument de type powerobject à ma fct° comme ça elle peut elle même faire un classname() sur l'argument pour récupérer son nom.

Et quel que soit l'objet duquel j'appelle la fct° ce sera toujours avec "this" comme argument pour ça, facile et peu de risque d'erreur comparé à devoir passer le nom de l'objet dans un string par exemple (risque de fautes de frappe, changement de nom d'objet etc.)

je voudrais arriver au même résultat pour ce qui est du nom de l'event/fonction courante.

connaissez vous un moyen de récupérer le nom de l'event / fonction courante ( celle qui contient le script en train de s'exécuter donc)

Le seul truc que j'ai trouvé c'est utiliser populateError() et l'objet error mais ce qui m'embête c'est que si je fais un populateError() dans ma fct° ben j'obtiens comme nom de fct° courante "ma fct° de gestion d'erreur" ce qui est logique car C'EST la fonction courante.

Et Faire le populateError dans la fonction où il y a l'erreur avant d'appeller ma fct° de msg d'erreur m'embête, ça voudrait dire qu'a chaque fois que je veux appeller ma fct° je dois appeller populateError avant et s j'oublie j'aurai des infos pas cohérente.

une idée qqun ?

( je précise si ça pouvait marcher en PB 6.5 ce serait top. )

Dernière modification par rincevent (25-06-2013 17:36:33)

seki · 11-04-2013 12:11:07

C'est tout l'intérêt des fastfuncs dont j'ai fait la démo récemment:
- ça parcourt tout seul la pile d'appel (en allant chercher dans les données internes de la machine virtuelle PB)
- ça ne nécessite pas de devoir bricoler avec l'objet erreur (où comme tu l'as remarqué soit tu alloues toujours l'objet inutilement, soit tu l'alloue quand c'est nécessaire mais il est trop tard car tu ne sais pas quel est l'appelant)

Malheureusement, je viens de vérifier que l'auteur n'a prévu des versions qu'à partir de la 10. Je ne sais pas si ça pourrait se backporter jusqu'à la 6.5.

rincevent · 11-04-2013 14:05:34

Salut Seki, oui j'avais bien pensé à ton post sur fastfunc et le stack mais je cherchais pour pb6.5

put... vivement qu'on abandonne ce fossile de PB 6.5 ...

PowerDestroyer · 25-06-2013 17:10:34

Salut,

Si tu ne peux pas utiliser FastFuncs, tu seras obligé d’utiliser PopulateError je pense, et à le coder explicitement à chaque fois que tu veux récupérer le n° de ligne/object/function.
Je te conseille de créer une fonction au nom court, du genre f_Error, qui prend un integer en argument, du coup tu codes sur une ligne:

Code: pb

f_Error(PopulateError(0, "Il y a une erreur ici"))

Comme tu es obligé de mettre le 0 à chaque fois (le code erreur), tu peux éventuellement l'utiliser pour typer ton erreur selon sa gravité, 0=>Info, 1=>Warning, 2=>Erreur fatale, ou selon l'action à mener en conséquence, 0=>Log, 1=>Message, 2=>Quit, par exemple.
Comme la fonction prend un integer en argument et non un string, ça limite le risque d'oublier de mettre le PopulateError.
Ta fonction f_Error doit toujours renvoyer FALSE, ou -1, c'est selon, mais ça te permettra de l'associer à un RETURN.
Par exemple:

Code: pb

IF (dw.Retrieve() = -1) THEN RETURN f_Error(PopulateError(0, "Le retrieve ne marche pas : " + dw.dataObject))

C'est un peu lourd, mais avec ça tu récupéreras bien le numéro de ligne où ton erreur s'est produite car le PopulateError est sur la même ligne que le retrieve.
Dans la fonction f_Error, après, tu peux faire pleins de trucs, stocker, logguer, afficher, déclencher un DebugBreak(), etc..

Have fun