You found your answer, but I am always curious why somebody needs this kind
of information, while he is in fact in the sub?
Cor
"Brahm" <daniel.brahm@c ontronic.com.br > schreef in bericht
news:O9gn43PgGH A.4708@TK2MSFTN GP04.phx.gbl...[color=blue]
> Hey Guys!
>
> is there anyway to get in runtime current function or sub name ?
>
> Daniel
>
>[/color]
We, for one, use this for code reusability, whereby all functions/subs that
can throw an error will call a global error message handler that logs the
message for troubleshooting when things goes wrong. Can't always rely on
the user to give us the details of the error. With this we know where and
when the error occurred.
"Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
news:%23VMQe9Vg GHA.3984@TK2MSF TNGP02.phx.gbl. ..[color=blue]
> Brahm,
>
> You found your answer, but I am always curious why somebody needs this
> kind of information, while he is in fact in the sub?
>
> Cor
>
> "Brahm" <daniel.brahm@c ontronic.com.br > schreef in bericht
> news:O9gn43PgGH A.4708@TK2MSFTN GP04.phx.gbl...[color=green]
>> Hey Guys!
>>
>> is there anyway to get in runtime current function or sub name ?
>>
>> Daniel
>>
>>[/color]
>
>[/color]
> We, for one, use this for code reusability, whereby all functions/subs[color=blue]
> that can throw an error will call a global error message handler that logs
> the message for troubleshooting when things goes wrong. Can't always rely
> on the user to give us the details of the error. With this we know where
> and when the error occurred.
>[/color]
But you are in the methode, why do you than need it to get it in that
difficult making only your program larger way?
Call("MyMethode ") seems for me easier than
Call(System.Ref lection.MethodB ase.GetCurrentM ethod.Name)
"+Vice" <tonyphan@earth link.net> wrote in
news:##6gMZYgGH A.4144@TK2MSFTN GP02.phx.gbl:
[color=blue]
> We, for one, use this for code reusability, whereby all functions/subs
> that can throw an error will call a global error message handler that
> logs the message for troubleshooting when things goes wrong. Can't
> always rely on the user to give us the details of the error. With
> this we know where and when the error occurred.[/color]
You're probably right, I need to look into that, all I really need to see is
the function/sub where the error began. I think the trouble I was having
with that, although I did not search deeper, was when a sub/function has an
error handler that calls a function that doesn't and so the call stack
incorrectly stated the function where the error was. Anyway, I'll have to
research further just never bothered.
"Martin Milan" <I8sp@m.i.do> wrote in message
news:Xns97D0BF6 5EBFC8I8spmido@ 194.117.143.53. ..[color=blue]
> "+Vice" <tonyphan@earth link.net> wrote in
> news:##6gMZYgGH A.4144@TK2MSFTN GP02.phx.gbl:
>[color=green]
>> We, for one, use this for code reusability, whereby all functions/subs
>> that can throw an error will call a global error message handler that
>> logs the message for troubleshooting when things goes wrong. Can't
>> always rely on the user to give us the details of the error. With
>> this we know where and when the error occurred.[/color]
>
> Use Exceptions - you can get a full call stack...[/color]
Are you saying that since you're already in the method then to call the
global error handler and pass it the method/function name? If so, it's too
much of a hassle when you have so many subs/functions to work with. Like I
said, we want reusability. For example, copy Call("MyHandler ") everywhere I
need a global error handler. However, I think I should bank on the call
stack for the global handler now. We do use a global Unhandled Exception
handler to capture any errors and it'll be nice to use the call stack to get
the sub/function name instead as suggested by Martin.
"Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
news:eCHQwdYgGH A.3900@TK2MSFTN GP05.phx.gbl...[color=blue][color=green]
>> We, for one, use this for code reusability, whereby all functions/subs
>> that can throw an error will call a global error message handler that
>> logs the message for troubleshooting when things goes wrong. Can't
>> always rely on the user to give us the details of the error. With this
>> we know where and when the error occurred.
>>[/color]
> But you are in the methode, why do you than need it to get it in that
> difficult making only your program larger way?
>
> Call("MyMethode ") seems for me easier than
> Call(System.Ref lection.MethodB ase.GetCurrentM ethod.Name)
>
> Therefore I still don't understand it?
>
> Cor
>[/color]
You found your answer, but I am always curious why somebody needs this kind
of information, while he is in fact in the sub?
Cor
"Brahm" <daniel.brahm@c ontronic.com.br > schreef in bericht
news:O9gn43PgGH A.4708@TK2MSFTN GP04.phx.gbl...[color=blue]
> Hey Guys!
>
> is there anyway to get in runtime current function or sub name ?
>
> Daniel
>
>[/color]
Comment