Is there a way to prevent Visual Studio from breaking on exceptions in a specific method?

Question

I know I can control the way Visual Studio handles exceptions according to their type and to the fact that they're eventually caught using the "Exception" dialog.

However, I've got a library that's internally throwing (and catching) an ArgumentOutOfRange exception when I'm calling a specific method. The exception is thrown (and caught by the library) maybe 1% of the time, but I'm calling this method a lot. The editor says it's by design (and indeed, the design they've chosen makes sense).

The thing is that I don't want Visual Studio to break each time the exception is thrown.

• I don't want to stop breaking on ArgumentOutOfRange exceptions, as I may have some in my code and want to break on those.
• I don't want to enable "just my code" debugging because I'm concerned about the exceptions thrown outside of my code (notably for performance reasons)

Is there a way to achieve this? I've been looking into attributes (such as DebuggerStepThrough), but haven't find something adequate yet.

Any hints on how to do this ?

Answer 1

I don't want to enable "just my code" debugging

Yeah, stop there right now. That is exactly the feature you need to not get the unwanted debugger breaks. If you don't want to know about somebody else's crappy code then flip that checkbox back on.

This invariably goes off the rails when programmers use exceptions for flow control. A very common crime. It takes two of them to turn that into a mess that turns a debugging session into a very tedious click nightmare. When you need the debugger feature that breaks on the first-chance exception then you basically lost if somebody else needed that as well.

Everybody hopes that they can magically use the [DebuggerNonUserCode] or [DebuggerHidden] or [DebuggerStepThrough] attributes to make that problem disappear. It doesn't. The other programmer did not think his code was unimportant enough to deserve those attributes. And, well, it wasn't because there's always a bug hidden in code that uses try/catch-em-all code. Pokémon code.

So Microsoft had to find another way to help programmers deal with crappy library code. They did. Tick that checkbox, bam, solved. Nothing you can do about that crappy code anyway, other than sending a nasty-gram to the author. Don't let us or Microsoft slow you down doing that as well, y'all have to get along to create a product that people like to use.

Answer 2

I think it's not possible in visual studio but it certainly is in WinDbg. See for example http://blogs.msdn.com/b/alejacma/archive/2009/08/24/managed-debugging-with-windbg-breaking-on-an-exception-part-1.aspx

On a side note it seems that starting with visual studio 2010 you can load and use WinDbg extension DLLs directly providing aditional functionality (including possibly the one that you need) but I haven't tried this yet - see for example http://www.dotnetcurry.com/ShowArticle.aspx?ID=648