Error Handling Question

[Rhino]

I recently read a post (via Google) that said it is usually a bad idea to
use reflection and that it is only rarely necessary since there are better
ways to do most things.

That has me wondering about something. When I handle an error in my
programs, I always want to obtain the name of the current class and the name
of the method that is executing for my error handling logic so that this
information can be logged and/or displayed to the user. For years now, I've
been getting the class name via getClass().getName(), i.e. via Reflection,
and I've hard-coded my method name in each method, e.g. String METHOD_NAME =
"foo()".

In light of the claim that reflection is usually the wrong approach to use,
what is the RIGHT approach to use in determining the name of the current
class and method? Or is my approach reasonable for my purposes?

I would especially love to hear a technique that would let me determine the
current method's name at runtime without having to hard-code it in each
method the way I am doing now; that has always struck me as a kludge.

--
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies." - C.A.R.
Hoare

 

[Chris Uppal]

I recently read a post (via Google) that said it is usually a bad idea to
use reflection and that it is only rarely necessary since there are better
ways to do most things.

....better ways to do most things /except/ any form of metaprogramming.

Attitudes to metaprogramming[*] (even in mild forms) are mixed. My own
opinions is that metaprogramming is ***GOOD*** (but that most languages suck
badly at providing the necessary tools, which means that it isn't often
appropriate where it /ought/ to be). Anyway...

That has me wondering about something. When I handle an error in my
programs, I always want to obtain the name of the current class and the
name of the method that is executing for my error handling logic so that
this information can be logged and/or displayed to the user.

Logging /is/ metaprogramming -- you are asking the running program to tell you
about its own operation. Either you use explicit metaprogramming constructs,
or you have to hack it in (simulate it) by hand. In the case of logging there
may be a performance question to be considered (logging can be a real drag on
application performance if done badly), but unless there is a performance
problem, I'd use reflection to read the stack to find the calling method.

I would especially love to hear a technique that would let me determine
the current method's name at runtime without having to hard-code it in
each method the way I am doing now; that has always struck me as a kludge.

Its something like:

(new java.lang.Throwable()).getStackTrace()

(I may have the spleling wrong -- check the docs). Also, you should be aware
that a JVM implementation is not required to be able to provide a stack trace,
but the chances are that it can, and that's good enough (IMO) for logging.

-- chris

([*] I'm using the word "metaprogramming" in a fairly wide sense, as any
programming which uses meta-level constructs/concepts -- which includes
reflection. Some people seem to use the term only for "programming the
meta-level" which is a much more hairy (and interesting) if you can do it at
all)

 

[Rhino]

I recently read a post (via Google) that said it is usually a bad idea to
use reflection and that it is only rarely necessary since there are better
ways to do most things.

...better ways to do most things /except/ any form of metaprogramming.

Attitudes to metaprogramming[*] (even in mild forms) are mixed. My own
opinions is that metaprogramming is ***GOOD*** (but that most languages suck
badly at providing the necessary tools, which means that it isn't often
appropriate where it /ought/ to be). Anyway...

Aha! So it isn't bad to use reflection for the purposes I've described.
Well, that's good to hear; no one likes to think they've been doing
something bad for a long time without even realizing it ;-)

Logging /is/ metaprogramming -- you are asking the running program to tell you
about its own operation. Either you use explicit metaprogramming constructs,
or you have to hack it in (simulate it) by hand. In the case of logging there
may be a performance question to be considered (logging can be a real drag on
application performance if done badly), but unless there is a performance
problem, I'd use reflection to read the stack to find the calling method.

kludge.

Its something like:

(new java.lang.Throwable()).getStackTrace()

(I may have the spleling wrong -- check the docs). Also, you should be aware
that a JVM implementation is not required to be able to provide a stack trace,
but the chances are that it can, and that's good enough (IMO) for logging.

So then I'd need to parse the stackTrace (assuming the JVM gave me one!) to
find the desired method name? Is it safe to assume that the method which
threw the exception will always be the first method named in the stackTrace?
Otherwise, I'm not sure how I'd be able to tell which source method was the
one whose name should be passed to the logger....

-- chris

([*] I'm using the word "metaprogramming" in a fairly wide sense, as any
programming which uses meta-level constructs/concepts -- which includes
reflection. Some people seem to use the term only for "programming the
meta-level" which is a much more hairy (and interesting) if you can do it at
all)

I haven't had any formal training in the concept of "metaprogramming" in
*any* sense. Just one of the many things I've missed as a result of learning
"by the seat of my pants" ;-)

Rhino

 

[Chris Uppal]

So then I'd need to parse the stackTrace (assuming the JVM gave me one!)
to find the desired method name?

Try this:

=======================
public class Test
{
void fruity() { apples(); }
void apples() { pears(); }
void pears() { peaches(); }
void peaches() { plumns(); }
void plumns() { cherries(); }
void cherries() { berries(); }
void berries() { hay(); }

void
hay()
{
StackTraceElement[] stack = new Throwable().getStackTrace();
for (StackTraceElement frame : stack)
System.out.println(frame.getMethodName());
}

public static void
main(String[] args)
{
new Test().fruity();
}
}

=======================

Is it safe to assume that the method
which threw the exception will always be the first method named in the
stackTrace? Otherwise, I'm not sure how I'd be able to tell which source
method was the one whose name should be passed to the logger....

In general for logging you know that the caller of the logging function is the
one that should be logged by name. It would be much easier for the logging
code to use reflection in one place to find out who called it, than for every
caller to have to find that information itself, so the logging code should be
looking for the second element in the array (unless there are several layers
/inside/ the logging code).

Exception reporting is different, that will depend on the details of your code,
but in general it's a bad idea to fail to record/report /any/ of the stack
contained in an exception that signals a genuine error. However you might want
to record the whole stack from the exception, but use the above to find out
"who" is /recording/ the exception (which may be different from where the
exception was /discovered/).

BTW, I assume that the common logging packages are able to do the above kind of
trick already, or at least can be configured to do so if you wish (though
haven't bothered to look ;-).

-- chris