current function / sub name ?

  • Thread starter Thread starter Brahm
  • Start date Start date
ok

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

"Brahm" <[email protected]> escreveu na mensagem
Hey Guys!

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

Daniel
 
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
 
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.
 
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.
Click to expand...
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
 
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.
Click to expand...

Use Exceptions - you can get a full call stack...
 
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.
 
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.
 
My intention is make error handler re-usable and generic.

Thanks.

BRAHM


"Cor Ligthert [MVP]" <[email protected]> escreveu na mensagem
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
 
Back
Top