[gknoy]

I've used "println debugging" more than I have used an IDE's debugger, and am more comfortable with the former. I think it revolves around a different way of using them, and is likely very heavily influenced by having spent a lot of time developing with a REPL handy.

When I did mostly Java coding, I would tend to use println debugging rather than dive into the IDE's debugger, as I tended to be able to zero in more easily on what was going on when I took a holistic "Let's print out each item's id and name ..." approach to start.

Now that I do most of my code in Python, I use the interactive debugger almost exclusively.

With an IDE, I can look at variables' contents. What do I do when I want to check the result of a method call, though? It is likely tool unfamiliarity, but it's never been clear how to check that as something to inspect. (If you know how to do this, then you're a much more savvy user of the IDE's debugging tools than I am.) If I don't have the right breakpoint, or the right questions, I often glean little.

Println debugging is an easy way to see that you're looping incorrectly, or that All Your Data is bad in a way you didn't expect.

With a REPL-style debugger, I can treat it as an interactive question/answer session that lets me check things like contents of the database, or the values that helper methods return:

  > print len(foo.items)
  0
  # why??? Maybe the objects don't exist?
  > print Foo.objects.filter(bar=42)
  [foo1, foo2, foo3]
  # Let me place a new breakpoint then in 
  # my JsFoo.from_db_item() method, and try again ....

I think the nicest thing about an interactive debugger is that it lets me construct arbitrary expressions -- print lists of things, look at nested data, etc -- in the language I am already developing in. I always had a hard time doing something quite as powerful in Eclipse.

[edwinnathaniel]

I used to do "println" debugging trick during my early days of programming until more senior people around me slap my hand and told me to use the debugger efficiently and effectively.

In Eclipse/IntelliJ you can set "Conditional Breakpoint" (only stop/break when certain conditions is met) very handy when debugging a loop. In addition to that, you can also set "breakpoint on any Exception".

Also, in Eclipse/IntelliJ, when the debugger hits the breakpoint, you could execute Java code within the context of that breakpoint (of course, java.lang is given by default in addition to the context of that breakpoint).

I've never done more complex debugging than that but I'm guessing you can write almost anything you want within the "evaluate window" in those IDEs.