Monday, September 17, 2012


Hi guys/gals,

Back to you after a long hiatus . Sorry about that, i was so busy, could not even pick up the laptop and open face book. However, today i took some time out to speak about something perennially important, namely : DEBUGGING .

Let me start by telling you that in the context of what i am speaking , there are two kinds of debuggers :

  1. People who like to use the all important SYSTEM.OUT.PRINTLN().
  2. People who like to use the inbuilt java debugger and the magical breakpoints .
Now i have been using RAD for sometime and it contains WAS6.1 to publish and deploy my web application . Let me come to my main point here. Since i was fully new to the application and i had to first know, how the code flows and so on and so forth, i tried using the java debugger . Now the problem here is that, coupled with WAS6.1 the debugger works really badly. It at times used to stop when i had not reached the break point which was supposed to show me the values for a particular variable, sometimes the WAS server used to stop by itself and would not start for 15-20 mins. All this heartache and i needed to find out many things very quickly. So, what did i do ? I went back to our very special friend system.out.println().

Now kindly bear in mind that i am not saying that you must not use java debugger. It's just that sometimes you may be short of patience and time to effectively  reap all the benefits of it. All those times, i suggest that you start using the sysout().It acts both as a tracer and debugger for the application.

You can , however use the log() method as well .One just  needs to import log4j.jar and log4j.xml and properties file where the logfile name and path is specified and voila you can start logging your information .

A little demonstration will not hurt, huh :

// In you base class :
public static log(String s) {
// Point to the appropriate trace level :
public Static DEBUG_LEVEL = "ERROR";
switch (DEBUG_LEVEL) {
case: ERROR
case : TRACE

Hope you liked it. Will be back next time, with something else . Keep in touch to see my next upcoming tutorial on Objective C  and the upcoming chapters on stepping into python and JS-OOPS .


  1. Kunal, I think there is a better way to handle this logging instead of the conditional code you have mentioned in this post. Essentially, we can mention in one of the properties file (log4j.xml I believe) where each of the log level messages should go and then use corresponding methods provided by log4j to log messages at that level.

    For instance, log4j.xml could be configured like

    for debug messages - log to file

    for warn messages - log to file

    for info messages - log to file


    And then logging can be as simple as logger->warn("WARN message"), logger->debug("Debug message"); logger->info("INFO message"); This we can avoid having conditional code just for the sake of logging.

    Just wanted to add this, so that I could better my understanding of log4j. Your thoughts ?

    1. Yes , GT you are very right and the examples that you have provided are correctly so. However, here the actual point that i wanted to point out was that java debuggers sometimes might not fetch us the exact result we want(more so when you have crappy WAS 7.0 and WAS 6.1) and hence people probably must then turn towards more conventional things like sysouts(might be a pain in the ass for being slow, but hey, i am not the one to complain as it's helping me since the debugger is not).I am not saying that lets have conditional logs, its just that it was given as an example to people to understand how it might be used to work. However, i do agree with you that conditional logs are not the best way to go and trace level logs(the info which you have so meticulously provided) are better for all environments. Thanks again , as your comments here might help another one in understanding the nuances of logging . Hey, got an idea ! Ok, next time i will come with a detailed chapter on this . That ought to help . What do you say ?