Every case…

Granted, I’m not 100% sure about Java IDEs (and would welcome any corrections that aren’t consistent with Java IDEs) because I use Visual Studio over C#/F# but adding variables to the watch list and using conditional breaks completely practically replaces println…

• you don’t need to rebuild to get additional information (you don’t even need to restart your process/debug session)
• you can remote debug a process on another machine
• you can move the current execution while executing (drag the arrow that indicates the current line)
• step into code/out of/over code based on whether or not you think it matters

And hell, I’m not even that great with the debugger, but it’s still light years ahead of console debugging or digging through logs.

The problem with println debugging is that the printlns themselves are a problem.

When you’re debugging using println, you have to modify your code to do it. This means you need to already know, or at least have a pretty good idea, where the bug is before you start debugging. And if you already know that, you probably don’t need to debug anyway, as (IME at least) the mian reason for debugging is to find where a bug is, not figure out how to fix it. Once you have the bug pinned down, the solution is usually obvious just from the context. (Not always, of course, but usually.)

If your println diagnostics turn out not to give you useful information, or not to give you useful enough information, you need to close the program, change the code, recompile, and then get back to the point you were at to reproduce the bug.

Once you’re done with finding and fixing the bug, you then have to change your code again to remove the println statements. (Let’s hope you don’t miss any and then ship the product with debug output left in!)

An interactive debugger doesn’t have these problems. You don’t need to know what you’re looking for ahead of time; you can examine the values of any arbitrary variable at any time it’s in scope. You don’t need to modify your code, because the debugger is external to your program. And therefore you don’t need to stop debugging, change your code and recompile to look at something new.

That principle alone–inspecting the code from the outside instead of having to instrument it (and then un-instrument it) manually–is the reason interactive debuggers have become the favorite method of debugging among modern programmers.

There isn’t really any information a debugger can give you that you could not gain through print statement as well, but…

it’s just so much faster and more flexible. Words can’t describe the power you get when you can freely look at what the code is doing while it’s running.

All in all, I’d estimate that using a debugger typically speeds up the debugging process 10 times. Probably 100 times in cases where there’s a lengthy build or deployment between the time where one print statement gives you information about where to next, i.e. where to add another print statement, and the time you can see the output of that new print statement. In a debugger, all it takes is a single click, maybe half a second. If you have to do a full rebuild and deploy to an app server, it could take half an hour.

in my experience, the eclipse debugger (or any step-by-step debugger, for that matter) helps a lot more than println statements, because:

• they don’t require several recompiles for what might be a small problem (this might seem like a small problem for small projects, but can quickly escalate for large to very large ones)
• they often allow debugger-time altering of the variables, which might be handy as well.

(these are just the most basic advantages I found)

However, the debugger is not always that nice:

• debugging multithreaded programs with a step-by-step debugger is pure hell. In the first writing step, I usually use a logging system with a byte-by-byte debug flag (think global debug, module 1 heavy debug, module 2 heavy debug, …). It’s saved me a lot so far
• debugging real-time programs where the real-time character is vital to the algorithm (the thing I have in mind was my personal version of face detection, which required the face to move smoothly. It didn’t when only getting a frame every couple of seconds because of debugging – granted that this could be solved by taking a video input, just giving an example)

in short: for small, handable projects a debugger is your largest friend. For large projects (which you often work on with a lot of people), an extensive write-time logging is your even larger friend. Or at least mine.

You should have googled it first. Debugger in Eclipse already contains a lot of functions that you don’t need to define. Other than that, System.out.println() statements might do for you in a simple small project but in a project where many members are working or you have large number of files, you just can’t keep adding these statements. It is good to have breakpoints.
I suggest you to take a look at this

I hardly ever find that I need the debugger – but when I need it, I really need it.

One nasty case is where you use println to print out an object, and it prints out “null”. After staring at the code for ages, you are convinced that the object cannot be null at that point. And yet, that is what println says. This can waste hours.

In the debugger, you will find immediately that the object is not null. However, the toString() method has been over-ridden to print out the value of some field in that object. The value of this field is, of course, null.

The debugger lets you explore a wider range of questions, more quickly, than using println. But in many simple situations, println is good enough. Just don’t waste too much time in those cases when it isn’t good enough.