A podcast on the city I call home - Bombay, by Suketu Mehta Author, "Maximum City".
http://www.itconversations.com/shows/detail769.html
Monday, March 27, 2006
Wednesday, March 15, 2006
Java tip - Get the method call hierarchy
So here's a small tip I learnt recently which I find useful at times. Quite often it is a pain to debug an application. You just want to have a trace from where a particular method was called.
Simply use this
<code>
MyClass() {
myMethod() {
new RuntimeException().printStackTrace();
}
}
</code>
Now whenever myMethod is called; a stack trace will be printed. So you can easily get the hierarchy of the calls made to reach that execution point. Notice that the Exception was not thrown; hence no handling is needed.
Simply use this
<code>
MyClass() {
myMethod() {
new RuntimeException().printStackTrace();
}
}
</code>
Now whenever myMethod is called; a stack trace will be printed. So you can easily get the hierarchy of the calls made to reach that execution point. Notice that the Exception was not thrown; hence no handling is needed.
Monday, March 06, 2006
JUnit Revelation
I stumbled upon this post by Martin Fowler via another blog. It's a bit dated (2004), but interesting. It reveals that JUnit creates a new instance of TestCase for each test method defined within it. The primary reason for doing this is so that tests are isolated from each other. That is tests don't share the state of objects. So they can be run in any order needed.
JUnit has two special methods setUp and tearDown (these I guess can be called anything in the newer version using Annotations) that are automatically run (if defined) before each test method. I wondered how they did this. Now it makes sense.
JUnit has two special methods setUp and tearDown (these I guess can be called anything in the newer version using Annotations) that are automatically run (if defined) before each test method. I wondered how they did this. Now it makes sense.
Subscribe to:
Posts (Atom)