By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,141 Members | 1,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,141 IT Pros & Developers. It's quick & easy.

current function / sub name ?

P: n/a
Hey Guys!

is there anyway to get in runtime current function or sub name ?

Daniel
May 26 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
ok

the answer is: msgbox(System.Reflection.MethodBase.GetCurrentMeth od.Name)

"Brahm" <da**********@contronic.com.br> escreveu na mensagem
news:O9**************@TK2MSFTNGP04.phx.gbl...
Hey Guys!

is there anyway to get in runtime current function or sub name ?

Daniel

May 26 '06 #2

P: n/a
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" <da**********@contronic.com.br> schreef in bericht
news:O9**************@TK2MSFTNGP04.phx.gbl...
Hey Guys!

is there anyway to get in runtime current function or sub name ?

Daniel

May 27 '06 #3

P: n/a
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]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
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" <da**********@contronic.com.br> schreef in bericht
news:O9**************@TK2MSFTNGP04.phx.gbl...
Hey Guys!

is there anyway to get in runtime current function or sub name ?

Daniel


May 27 '06 #4

P: n/a
> 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.

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.Reflection.MethodBase.GetCurrentMethod .Name)

Therefore I still don't understand it?

Cor
May 27 '06 #5

P: n/a
"+Vice" <to******@earthlink.net> wrote in
news:##**************@TK2MSFTNGP02.phx.gbl:
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.


Use Exceptions - you can get a full call stack...
May 27 '06 #6

P: n/a
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" <I8**@m.i.do> wrote in message
news:Xn**********************@194.117.143.53...
"+Vice" <to******@earthlink.net> wrote in
news:##**************@TK2MSFTNGP02.phx.gbl:
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.


Use Exceptions - you can get a full call stack...

May 29 '06 #7

P: n/a
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]" <no************@planet.nl> wrote in message
news:eC**************@TK2MSFTNGP05.phx.gbl...
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.

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.Reflection.MethodBase.GetCurrentMethod .Name)

Therefore I still don't understand it?

Cor

May 29 '06 #8

P: n/a
My intention is make error handler re-usable and generic.

Thanks.

BRAHM
"Cor Ligthert [MVP]" <no************@planet.nl> escreveu na mensagem
news:%2****************@TK2MSFTNGP02.phx.gbl...
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" <da**********@contronic.com.br> schreef in bericht
news:O9**************@TK2MSFTNGP04.phx.gbl...
Hey Guys!

is there anyway to get in runtime current function or sub name ?

Daniel


May 29 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.