Reputation: 63905
I work on a quite large legacy codebase. Because it's not always been maintained the best, sometimes exceptions are used from control flow, or for varying other reasons. And there are times where it is nearly unavoidable For instance, how else do you check if a file is a valid .ico image other than pass it in as an image and see if it doesn't throw an exception?
I refactor this kind of stuff where I can, but many times it's just too expensive to refactor for little gain. These bogus exceptions become extremely annoying when debugging. We catch all exceptions to avoid our program ever crashing, and catch most exceptions and display something a bit more user friendly. So, when debugging, if some piece of code throws an ApplicationException
, there might be 50 exceptions of that type thrown before we finally get to the actual bug. Most of the time these bogus exceptions are focused around a single part of code(many times a single line). Is there any way I could get Visual Studio to ignore exceptions thrown from that line, but still stop on the exception that is the actual problem? Or is there anything else I can do to help prevent this kind of debugging frustration?
To illustrate my problem, imagine something like this:
for(int i=0; i<foo; i++)
{
try
{
FooBar(i); //this function throws NullReferenceException sometimes
}catch {} //ignore it because we don't care if it failed
}
....
var tmp=Bar as FooType; //this cast fails so tmp is null
tmp.Meh(); //throws exception here. This is a bug, we should've checked for null
If you wanted to figure out where the NullReference is, you basically hold down F5 until you're past the FooBar
calls. This is annoying at best, and quite error prone
Upvotes: 24
Views: 4001
Reputation: 8589
From what I see you can combine multiple techniques of debugging to improve your refactoring process.
If possible you can place (parts of) the legacy code into seperate assemblies. Compile those with optimization and enable "Just my Code" debugging.
For smaller blocks (Methods) you can use the DebuggerStepThrough Attribute, so the debbuger won't break there. For your example you could create a method that permorms the loop which calls your FooBar Method and place [DebuggerStepThrough] on the newly created method. Alternativly you could refactor FooBar to handle the exception and place [DebuggerStepThrough] on that.
Upvotes: 1
Reputation: 1826
I develop IntelliDebugger - extension for Visual Studio, which facilitates debugging C++/C# code. Including work with exceptions. IntelliDebugger can filter exceptions that have been thrown out of modules are not included in the Solution (this feature called ”Break exceptions only from Solution”). Perhaps this feature will be useful to you.
In future versions we are planning to add a better filter and other features to work with exceptions. If you have any feature requests or bug reports, please write to me. This will help us make the product handy specifically for you.
Upvotes: 0
Reputation: 3408
You can tune on what exceptions types the break occurs. See Debug -> Exceptions in menu http://msdn.microsoft.com/en-us/library/d14azbfh(v=vs.80).aspx
Upvotes: 1