[quote name='Olof Hedman' timestamp='1348315848' post='4982635']
What? I really have no idea what you are talking about now... how could I apply that to either?

"If <something> wasn't useful, it wouldn't exist" <- is a truth-free assertion. Lot's of things exist that aren't useful. But that's beside the point.
[/quote]

In general, yes. But in this context of tradesmen's tools, this is rarely true.
Tools that aren't useful gets forgotten or replaced.
Lots of statements makes no sense when taken out of their context.

I don't use my debugger as quality control in the way you describe, I use it to quickly track down problems in my own and other peoples code.
I find it's extremely useful to check my assumptions about the implementation with real life data, without having to pollute the code with asserts and printouts.
Things like watchpoints and memory dump views makes it easy to quickly see that each step of the process is behaving as expected.
I can quickly set up tests and tweaks on my code and see if the behavior changes as the current theory assumes.

I don't understand why people make such a big deal about it really, its just a quick way to find problems, and to quickly check if your assumptions about what the problem really is, is true...

Its not replacing anything, its just another tool you can use, making you an even more productive coder if used right. (like any other tool in software engineering really)
Sure, in a perfect world, of perfect software engineering, where all code is written by (bugfree) AIs, debuggers will be useless, but they are still very useful now

Talking about Quality Control, you shouldn't under estimate code reviews. (which this stepping through each line is a variant of). At one place I worked, we were forced to go through each line of code with a colleague, explaining what it did. Everyone was groaning, but you'd be surprised how many small potential issues where found that way. (I don't recommend that in general though, but on some critical software, it might be motivated)

Each time you step through your code, you are validating one particular path through your code. If you are very diligent (and have good test coverage), you might step through each test path. But these are still all only testing your "happy paths" (if you have written a test, then that path has an expected outcome => happy path). And your happy paths are already tested.

I think that even falling for a trap like that is its own kind of dependence on the debugger.

Also, I'm surprised people are still posting here. I completely forgot. I guess when you question something that so many people like, you're bound to get everyone talking. At least it's been flame-free thus far.

To be completely fair, I told him that using a debugger helped me with a lot of null references when I was trying to handle data from files that somehow never loaded up during runtime (something I've always thought was a fairly common, small mistake people make), and his response was that those situations rarely arise for him.

Ok, now we get to the crux of it. Using a debugger is NOT lazy, however using a debugger as a replacement for propper runtime checks & logging is lazy (and bad practice). If you delete all of your assets, and then run your app, does it A) crash, or B) gracefully handle the runtime error, and print a log entry + error dialog? If the answer is A, then you have more work to do. I think I actually agree with your professor here......

To me that seems like a questionable claim, but again, I'm just a beginner.

It is entirely reasonable, and entirely likely. I've worked in mddleware before, and I've had to unit test asset loadng code to the point where it would never fail. It's not actually difficult to achieve, you've just got to apply due diligence.

Furthermore, he said that he just uses error messages to let him know whenever something goes wrong. But isn't that in itself a flawed idea to begin with? Since you only put error messages where you expect errors to occur, when a problem pops up in an unexpected place your error messages won't mean anything.

An expected error of attempting to load an asset, is that the asset cannot be found on disk. I'm absolutely certain this is what the professor was talking about. Using a debugger to catch these errors is a terrible approach, and a habit you should unlearn as soon as possible.

A debugger is a good tool to help track down difficult to diagnose problems in your code. It is not a tool that allows you to avoid writing error handling mechanisms. (As an aside, I probably use a debugger once a month maybe. Unit tests have largely eradicated my need to use one on a daily basis....)

[deleted because I'd like to just withdraw from this conversation while the withdrawin's good]