oh yes, we've all been there

Check! It also underlines the importance of using decent, descriptive error messages.

oh yes we've all been there

The stack trace is there only for obfuscation purposes. It hides the real error message deep inside some garbled text. Would it be a real pain to have the root error message shown first and an option to see the full stack trace? Maybe not, but then unenlightened mortals could understand what's the problem and all the magic would be gone.

It seems that java web application stack traced are always hundreds of frames deep. I mean literally hundreds. Java frameworks tend to be very abstract.

Ummm... 99% ? You sure about that... ? I think its probably more like 25% at the most

The debugger is definitely seriously overused. Many (most?) ASP.NET still use F5 (defaults to build->attach debugger->launch the web site at the start page) to test every single modification they do. What used to be a 2 second process in "classic" web development has turned into a 2 minute process.

I guess it's Visual Studio's fault, but seriously. Just build (if necessary) and reload!

Been there, done that.

In my worst case it was an exception that was happening in the UAT environment. I could not reproduce it in development, and the top-level exception didn't shed any light. My instincts said "need debugger, grunt" so I went and started installing Visual Studio on the UAT server. I was trying to look for ideas on the web while waited for the installation to finish when I thought I'd check the exception again, reading down the stack revealed exactly what configuration issue I had. Roughly 2 hours I wished I had back at the time. :)

99% is probably a bit high, but I'd vote in-around the 75% range.

The scenario of gunteman is, sadly enough, really true. I had sometimes people calling me, asking for help in finding the reason for a bug, and simply reading the exception text or stack trace I can point out the solution.

The main problem is that programmers lacks a formal training in the field of testing and debugging program.

If you change a query in the DataLayer and press F5 to

1) Start web application

2) log to the site

3) navigate to the page that exercise the query

4) Put a breakpoint in the query and step into the debugger to see what is happening.

you are wasting time, and is not fault of Visual Studio, is the fault of the programmer that does not know any other way to test a piece of code than to press F5. :)

alk.

Hmm where is that formal training. Last time I checked most universities are still using clay tablets, C++, and still hoping Linux will catch on. Sadly developers are left to become a journeyman and darn that continuous learning. This is the primary reason schools always have the hardest time finding internships for juniors and seniors. Practical skills from college usually approach zero with the traditional CS program.

Sadly enough, university is not the right place to have formal training. Developers needs to Buy Book, exchange ideas with others, and always learn learn learn.

I tend to do the opposite, I almost always avoid compilation. I do a lot of web application development in VS, and cringe when I have to make backend changes that require a recompile... In some cases, a couple of lines of backend changes to support a swath of front-end adjustments. 2-5 minutes gone in that process.