5 Replies - 1152 Views - Last Post: 17 July 2012 - 07:51 PM

#1 BrendanH  Icon User is offline

  • D.I.C Head

Reputation: -2
  • View blog
  • Posts: 174
  • Joined: 05-May 12

Debugging in Java

Posted 16 July 2012 - 02:46 PM

As most of you know academic institutions that teach Java Programming dont really teach alot of how to debug programs.
Would anyone know where the best place to start learning how to?

Thanks!
Is This A Good Question/Topic? 0
  • +

Replies To: Debugging in Java

#2 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3662
  • View blog
  • Posts: 11,465
  • Joined: 05-May 12

Re: Debugging in Java

Posted 16 July 2012 - 03:29 PM

Do you mean learning how to debug in terms of the mechanics of using a particular debugger or an IDE and examining variables, setting breakpoints, etc. ?

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. ?
Was This Post Helpful? 0
  • +
  • -

#3 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7999
  • View blog
  • Posts: 13,701
  • Joined: 19-March 11

Re: Debugging in Java

Posted 16 July 2012 - 03:32 PM

One of the smartest people I've ever come across has observed that the best way to debug a program is not to write the bugs in the first place.

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

Was This Post Helpful? 3
  • +
  • -

#4 lordofduct  Icon User is offline

  • I'm a cheeseburger
  • member icon


Reputation: 2538
  • View blog
  • Posts: 4,641
  • Joined: 24-September 10

Re: Debugging in Java

Posted 16 July 2012 - 04:25 PM

what jon.kiparsky has said may seem a lot like 'cart before the horse' because how would you know any of that stuff with out already knowing it.

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.
Was This Post Helpful? 4
  • +
  • -

#5 dorknexus  Icon User is offline

  • or something bad...real bad.
  • member icon

Reputation: 1256
  • View blog
  • Posts: 4,618
  • Joined: 02-May 04

Re: Debugging in Java

Posted 17 July 2012 - 04:59 PM

Basics of JDB (java debugger)
Was This Post Helpful? 2
  • +
  • -

#6 jon.kiparsky  Icon User is offline

  • Pancakes!
  • member icon


Reputation: 7999
  • View blog
  • Posts: 13,701
  • Joined: 19-March 11

Re: Debugging in Java

Posted 17 July 2012 - 07:51 PM

"Debuggers" have to be the most ineptly-named tool in software development (aside from "groovy" which is just an awful name). They are not actually debuggers, in that they don't debug your code. They just slow it down so you can see what's happening - something that you can already do with your own brain in almost all cases, or you should be able to do.

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.
Was This Post Helpful? 3
  • +
  • -

Page 1 of 1