That whole breakpoint thing
My students are currently working on their final assignment. All four assignments in this course are based on a single application. In the first assignment, they wrote business objects, they developed a UI in the second and a data access layer in the third. In all three, I supplied the other two layers, and so they could be counted on to be reasonably bug free. The students had only to figure out and debug one layer at a time.
In the fourth assignment, they have to implement a vertical slice of the application - adding a couple of new screens and a supporting business object and data access class.
These are actually simpler than the stuff they have done in previous assignment, but the difficulty is that if anything is wrong, the problem could conceivably be in any layer and the students will have to find it. I'm trying to put a bit more realism into the task.
Anyway, one students spoke to me after the lab and said that her expense list wasn't showing the correct rows, it was only showing new rows not existing ones.
I advised her to set a breakpoint in her code and step through line-by-line to see exactly what was happening.
"I haven't really figured out that whole breakpoint thing yet", she says to me. WTF?!? This is week 11! Of 12!
I'm going to assume that most of you reading are geek enough to have programmed using a decent development environment. Setting breakpoints and stepping through them is essential to debugging. Debugging without them involves putting System.out.println or echo or alert every second line (or your language equivalent). It's like trying to row a boat across the Tasman instead of flying a plane.
It's not like I expected the students to figure breakpoints out for themselves (after all, their previous programming environment in Java was Notepad and the command line). I showed them in class, in tutorials and in labs. And in every single lecture this semester I have had demo code, and almost every time I showed it, I set a breakpoint and stepped through it to show them what was happening.
How can she not have figured out that "breakpoint" thing after 11 weeks of a programming course?
Anyway, I politely recapped the basics of breakpoints, and off she trotted.
Two days later, I get this email: could you pls have a look at my code. because I m still stuck at that point. my expenselist is still displaying new row.I am not quiet sure wat I am doing wrong
Not quiet sure indeed.
The expenselist in question is a grid view that should be bound to a collection of expense objects. My working hypothesis was that she was returning a collection of objects that were based on newly created database records rather than being based on rows already in the database. I opened up her project to set a breakpoint on her databinding code so that I could trace through and find out where the problem was. This was her UI code:
Public Class Expense
End Class<
Dumbass! How the hell do you expect to see anything if you don't write any bloody code? Visual Studio is damn good but it isn't magic - you can't make something happen just by thinking it.
But of course, I didn't say that. I very politely replied to tell her that the problem was that she hadn't written the code to do the databinding yet.
The following day, she emails me back with: thanks alot i figured out how to do it
Well, that's great honey, I'm glad that you have now figured out how to do the basic, simplest databinding task that we learned in week 4. Maybe next week you'll figure out "that whole breakpoint thing" from week 1.