Anybody have a favorite book or website on .NET C# debugging techniques? Or general debugging techniques? I've been tasked with coming up with a policy on debugging for our web team and want some outside input as I KNOW my techniques are hacks at best...

TIA

Lots and lots of DUMPS and output messages... When that fails, try common sense. And if you still can't get it, consult a 4 year old because they seem to know more about computers than anyone else these days.

that sounds about like my technique...

We're wanting to come up with a formal doc & maybe some debug classes etc....I've found some nice stuff on the net about conditionals but wondered if anyone had used anything in practice.

Seriously, there is something to be said for simplification. If you have a page that's doing X, Y, and Z, and it won't run at all, then start removing letters till it does.

Another thing is to look for exceptions, especially when doing any kind of comparison or mathematical operation. Oddball values such as a NULL or empty string or a divsion by zero often crop up long after you think you've finished, and sometimes result in the strangest errors. Speaking of NULL - it should probably be a separate section altogether if you make this a multi-part class; I know of several languages that have separate operators for comparing NULL values rather than the standard equality (i.e. CF uses "IS NULL" rather than "=")

And if all that fails, go find a four year old.

mmm... i use the heck out of Try...Catch blocks. When an exception is thrown I have a generic subroutine that gets the exception, assiciated SQL statement if there is one, and then it shoots it off to me in an email with date, time, page, and line that it occured on (all held within the exception object). Other than that.... no. But I think too many people don't use good exception handling... I mean just by wrapping in Try...Catch blocks you can accomplish alot without bombing your application.

Until recently, I never used exeption handling. I always did tight validation and have never had a problem.

The .net framework includes trace and debug commands. I would recommend doing a search on those to see what they offer. I am just now exploring those options but I have found a limitation in that it only shows the values after a page is completed. I want to see the values before a page is completed as well so I can do some comparisions.

Personally I have never seen any good books on debuging. I have always written my own code and functions to display output. The trace and debug are supposed to simulate what I have done, but as I have said I have not played with it yet.

My method was setting up debug block that only I could turn on and view while going through the site. This way I can see the values change the the functions there were being called. I also had a seperate page that I loaded a child to the window to display application and session values along with memory usage.

I've used the old standard


And it's worked well for me. I want to get to a more robust and professional debug policy though. Trace & Debug commands are on my list of things to look up as well as more on stack traces & output of that data.

TRY and CATCH blocks aren't really debug elements as much as they are error handling wouldn't you say? I use them all the time as well, everywhere I can. Conditional classes are also high on the list as they seem to be basically the same as the code fragment above but on a class level, not just a statement level.

Try/Catch Blocks in ASP.Net Applications cause a very significant performance hit. In our tests, we saw a 62% performance hit when using them vs. not using them. This also comes from Microsoft directly, at their MSDN events, PDC, knowledge base, whenever talking about performance, they always steer you away from using Try/Catch where ever you can.

If you search, I do rememeber a MSDN or PDC article that talked about the actual performance hit when you use exceptions, it talked about what happens behind the scene when the asp.net handler has to load code with and without exceptions.

Granted, in some cases, it is worth the hit, but when using shared servers that can get sluggish already, performance is something you have to watch.

Regards

I agree with sforker, there are performance issues with Try Catch blocks as they attempt to use internal error handling and generate some quite astonishing degradation. I prefer to use the try catches for the development then remove this for production servers. Buy the time code reaches production there should not be any bugs.

Granted bugs still occur, and as such I tend to write a simple custom error page that sends me an email with the error code. Customer is happy cause the site looks professional and you are happy cause no one sees a simple bug, which you can configure to email you all the details you need to fix, rather than having someone try and explain the problem