I have a situation where I have a method 'x' in a class 'A'. And I have couple of main classes I mean the classes which have main method, where we call this method 'x' in class 'A'. So I have to determine at runtime in the method 'x', from which main class the call came from and then do some operations. I cannot write another method passing some arguments or keep any identifiers because everything is already defined and implemented. I mean I am not supposed to make any changes in the existing code. Any ideas.
Originally posted by Keith Lynn: What about creating an instance of Throwable and looking at the stack trace?
To expand a bit on what Keith said - if you're on 1.4 and above you can use Throwable.getStackTrace() (can't directly link to method in this forum) to get an array of StackTraceElement entries. You could then examine them to see where you came from.
<a href="http://forums.hotjoe.com/forums/list.page" target="_blank" rel="nofollow">Java forums using Java software</a> - Come and help get them started.
Thanks guys for your reply. It worked. But Stan, do you think it isn't an efficient way to do things. Because my application demanded this scenario. Can you suggest any other option for this kind of situation.
If you have "if called by X do this" I'd look for a parameter to express real knowledge about what's going on, like "if tuesday do this" or "if taxExempt do that". Checking the caller name tells me nothing of the real reason for the logic. Write code that tells a reader a story about what you're trying to do in the plainest way you can.
Also, a class that has to know who called it cannot be reused without change. If I want to call it from a new caller I have to open it up and add a test for the new caller.
25 years ago I had a temporary assignment on a COBOL system where modules had dependencies on who called them. It was a nightmare to figure out or change and still makes me jumpy when this topic comes up.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by stephanie coy: Thanks guys for your reply. It worked. But Stan, do you think it isn't an efficient way to do things. Because my application demanded this scenario. Can you suggest any other option for this kind of situation.
What are you doing differently for the various callers? What are you doing the if/else on: the calling method name, the calling object, or the calling object's class?
And I have another option here, if I could in anyway findout the command line arguments passed in the main class, in the method being called(which is originally in another class), I think I can do what I am supposed to do. Any ideas about this.
I'd rather print the stack trace and avoid any interest in who the caller was.[/B]
I think that more commonly, the goal in logging is to reliably log the name of the class, method and line number that's calling the log method. Without requiring the programmer to type anything extra when logging. So the code would look like:
and it would be up to the log() method to figure out the context and provide a spiffy formatted message in the log file:
In fact Log4J does exactly this sort of thing for you. You can specify a format for the logged messages, and if you ask for a format that includes class, method, or line number, Log4J will kindly create a Throwable and figure out for you. Of course this can be prohibitively slow in some cases, so the documentation warns that performance may be an issue. Like most performance advice, it's irrelevant most of the time, but can be significant in a tight loop.
Anyway, back to Stephanie: there are a few ways I can think of to do this, but they involve changing the code in the main() method - and you've said you can't do that. If that's still an absolute requirement for you, then creating a Throwable may be your best option. I'd comment the code saying that yes you know it's a horribly ineffecient solution and more importantly a confusing design for others to work with, but you're prohibited from touching any of the other classes. Some times poor decisions are imposed on us by management (sometimes they even make good sense in a larger context, just not in the program you're working on). Maybe the best thing to do is just do something ugly that works, document it, and move on. [ June 07, 2006: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
They worship nothing. They say it's because nothing lasts forever. Like this tiny ad: