5 Replies - 1335 Views - Last Post: 17 July 2012 - 07:51 PM
Debugging in Java
Posted 16 July 2012 - 02:46 PM
Would anyone know where the best place to start learning how to?
Replies To: Debugging in Java
Re: Debugging in Java
Posted 16 July 2012 - 03:29 PM
Or do you mean learning how to debug in terms of techniques like isolating the source of the problem by dividing (eg. Does the problem happen before this phase of the program or after?); forcing error conditions by changing variable values; etc. ?
Re: Debugging in Java
Posted 16 July 2012 - 03:32 PM
That sounds flip, but it's actually pretty deep: if you know the the code you're writing well, you make fewer mistakes. The better you know the language, the libraries, and your own logic, the easier it is to write code and not make mistakes.
One of the best ways to achieve this state of understanding, or to get closer to it than you are today, is to learn from your mistakes. From this it follows that the more mistakes you've made, the better the code you'll write, assuming you've learned from them. (although this is not strictly reversible, you can generally assume that it is: this implies that the people correcting your code have made a lot more mistakes than you have... this sometimes helps understand where they're coming from).
So, inexorably, the thing to do is to make lots of mistakes. The way to do that is to write lots of code, and pay attention to what you write and how it works. If you're not making enough mistakes, try more complicated stuff.
Another useful thing to do, I find, is to study libraries. Learn the core libraries. Start with the String class, and just go through it, writing little programs that test each of the methods it offers, to get used to reading the API and to train yourself to understand them. This also gives you ready access to those methods, since they'll be in your head where you want them to be. From there, maybe review the wrapper classes for the primitives, then start going through the Arrays methods, then the classes in java.util, and so forth. Just set aside an hour or two or three a week and learn libraries - make sure you write code for them, too, that's sort of the point.
Okay, so those sort of help you get hip to what you're looking for. It's easier to see mistakes if you know what the right thing looks like.
Now, you want to make your mistakes stand out. Always format your code correctly. Do it manually, at least while you're learning the basics, so you build the structures into your brain. Again, you want to have a visceral idea of what a mistake looks like, and if your braces and your indentation don't line up, you want that to leap out at you.
Finally, structure the code itself to minimize repetition and maximize modular code flow. Make it easy trace a portion of the code from point to point, by making short methods that do small things instead of big methods that do everything, and make sure you only have to fix a problem once by only writing that piece of code once.
After all, if you write the same piece of code four times, that's four times as many potential bugs.
None of that has anything to do with debugging per se, it's all about pre-bugging, but you should try to start there. Start by making it harder to commit a mistake.
Then you can start thinking about debugging.
This post has been edited by jon.kiparsky: 16 July 2012 - 03:35 PM
Re: Debugging in Java
Posted 16 July 2012 - 04:25 PM
And it all stands for any part of coding, not just learning to debug.
But the point stands, you need to know what you're doing to know what you're doing wrong.
Learning what it is you're breaking helps in fixing it... but you haven't learned that yet, and breaking it is how you're going to learn, but how do you find the breaks.
I basically unit test to find them. I break my projects into tiny parts and test those little parts (you don't necessarily need to follow some unit testing model, your code might not be organized enough yet to easily follow them... but keep it in mind, just like you should keep any standards in mind, as you learn).
Explore the different tools your debugger might have when doing this... you can read the documentation for it (each debugger is different) and just mess about with it.
Re: Debugging in Java
Posted 17 July 2012 - 07:51 PM
This brings us to actual debugging.
Debugging is simply identifying an incorrect behavior and tracing it to its origin. Once this has been done, changing the behavior is generally trivial. The first step is to identify the point in the code where the bug becomes apparent. This will generally be a point where some output is performed, and is seen to be incorrect. At that point, it is clear what is wrong: the wrong value is in some location in memory, and we know where that location is: it is in the location that is being printed. How did it get to be that way?
If you have designed your program well, there will be a very short path to trace from a direct assignment to each variable used to the final calculation in which that variable is involved. This is convenient, because it means that it is possible to trace each variable from its assignment (presumably in a method's parameter list) to the result of that final calculation.
Either that assignment is incorrect, or the path of the execution is incorrect, and by writing small methods, it is easy to tell which. If it is the latter, fix the execution, and the problem should be solved. If it is the former - if the incoming value is incorrect - then determine where the incorrect value came from, ie, where this method was called, and figure out why it was called with the wrong value. This will be the same process I've just detailed.
If you're not sure about whether a method is working correctly, call it with values for which you can calculate the correct result. Make sure you're not using some special case values, ie, make sure you test it sufficiently.
This is the most general method of debugging a program that I know of for interesting bugs - functioning code that produces incorrect results, possibly intermittently. It's an exhaustive method, in that you start from a place where you know there is a failure and you work your way back until you find where you introduce the failure. It is a replacement for intuitive debugging, which is great when it works and useless when it doesn't.
Intuitive debugging is pretty simple: you read the code and you run it in your mind, and you envision the resulting state of the code as it develops. When you see the error occur in your mind, you then know exactly how it happened - if your internal compiler is good, which will not always be the case.
A variant on this method is called "rubber-ducking". You call over one of your co-workers, and you tell them what the problem is, and you explain to them how this couldn't possibly happen, because you do this here, and this there, and you check that over there and then....
oh. Yeah, I missed setting this to that. Never mind.
"Rubber-ducking" comes from the practice some programmers follow of keeping some co-worker stand-in handy, like for example a rubber duck, and explaining the problem to the rubber duck instead of bothering your colleagues.
These are all good for identifying logic errors: the code compiles and does the wrong thing. There are other things which are called bugs sometimes, for example code which doesn't compile or which throws errors on running. This stuff is generally trivial: in Java, particularly, the compiler tells you what the problem is, you just have to read the compiler output and understand it.
There you are. Go forth and debug.