Eclipse WTP – Try, Try, Try and Nothing Else

On Tuesday(2/17) Angel Vera from IBM came to our class as a guest speaker. He showed us how to use the “Search” feature on the Plug In development platform to locate the fragment of code that was manifesting the behaviour of a bug. His search strategy was as important as the “Search” capability given by the IDE. He picked a word from the GUI that was under investigation. Then he searched through the properties files that have to do with NLS. Then he grabbed the key from a properties file to do a search among Java source files.  When the class was over, I asked him if it’s all right to insert a line of code to throw an exception. The stack trace from the JVM might give me a clue about the location of the bug. Well, he said that he and other developers sometimes would do that. Also, they would use System.out.println. He said, “Don’t be afraid to try out anything with the code.”

Tonight I was trying to map out the flow of control that has triggered NullPointerException that is related to my bug. After some tinkering, I used the”Search” feature and found out that the dropDown method was called 12  times in the ASDCCombo class. Then I inserted some System.out.println statements near those locations. The output in the console view on the development platform has given me an interesting trace of events and event handling. I still don’t know why there’s a null reference. Soon I realized that I should get an updated stack trace report since I’m using the most current build(3.1M5). I don’t know how to do it. I posted my request to the Bug Report.

After Angel Vera’s visit to our class, I felt somewhat empowered to fix the bug. He and Jordan have shown us different ways to locate a bug. What I and other students need to do now is try, try, try and nothing else.



2 Responses to “Eclipse WTP – Try, Try, Try and Nothing Else”

  1. Tony Lai Says:

    Hey Peter!
    That’s what I’m currently doing in the mozilla code!
    Sometimes in certain areas of the code, printf statements won’t show in the debugger, so I put NS_ASSERTION(0, “Message”); statements.
    In mozilla, NS_ASSERTION checks for a condition (first parameter, where I put 0) and if it is false, throws an assertion with the message.

    Since the printf statements don’t show in the debug command line… I found this a nifty way to test things.

    Glad to know someone else thought about throwing exceptions also 🙂

  2. Jordan Says:


    Thank you very much for your work and for being part of our small community.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: