0

I know it isn't good practice to intentionally rely on exceptions in program flow. But there are times when it is necessary:

eg. There is no Json TryParse method that I can find that does not rely on an exception being used to return a false value.

How can I debug and break on all exceptions EXCEPT for these intended exceptions?

-- Edit (I'm still struggling with this) --

Let's say I use the code shown in the first answer: How to make sure that string is valid JSON using JSON.NET

Under some circumstances, the code will intentionally handle a JsonReaderException and return false.

When this occurs, I do NOT want the debugger to break on that line. However I do NOT want JsonReaderExceptions ignored elsewhere in my code.

Can I ignore the exception only in this one method?

--

I see that I can ignore an exception type across and entire assembly https://devblogs.microsoft.com/devops/break-on-exceptions-thrown-only-from-specific-modules-in-visual-studio-15-preview/

This approach isn't satisfactory, because I often work with COMExceptions, and there's no way that I would intentionally ignore all COMExceptions in an assembly.

I thought it would be possible to ignore an exception in a more fine grained manner. I expected to be able to decorate my method with an attribute that instructs the debugger to continue. Something similar to [System.Diagnostics.DebuggerStepThrough]

Matt Fitzmaurice
  • 1,319
  • 4
  • 19
  • 40
  • Put it in a `try catch`, *breakpoint* the `catch`? or have I misunderstood you? – TheGeneral Oct 16 '20 at 04:59
  • If I have understood you can use VS's **Exception Settings** window to pick which exceptions to break on. i.e. it stop's at the point the exception is _thrown_ not when the exception is _caught_. _[this might help - blatant self-promotion](https://stackoverflow.com/a/34172404/585968)_ –  Oct 16 '20 at 05:05

2 Answers2

1

You could just derive from the exception class and put a break point here:

class BreakOnException : Exception
{
    public BreakOnException (string message)
        : base(message)
    {
       //break point
    }

}

Or use the Exception settings: MSDN: Tell the debugger to break when an exception is thrown

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
1

Debug menu, Exceptions window, put a tick next to CLR Exceptions

Run the program; it'll now break as soon as an exception is thrown, which is probably "too often"

When a break occurs , open the exception helper tooltip-panel and remove the tick from "break when this type of exception occurs"

This means you'll gradually eliminate the kinds of exceptions you aren't interested in, without having to find them in the Exceptions window tree (it's a pain)

Caius Jard
  • 72,509
  • 5
  • 49
  • 80
  • I think my problem is that I don't want to eliminate types of exceptions. I want to eliminate one specific exception -- Please see edited question above. – Matt Fitzmaurice Nov 03 '20 at 03:40
  • You can eliminate that one specific type of exception by ticking them all off and then finding the one in the tree (expand CLR Exceptions) and ticking it on, though honestly I find it easier to tick all of them on and then as exceptions occur that I don't want, I untick "break when this is thrown" in the exception helper – Caius Jard Nov 03 '20 at 07:52
  • I suppose also if you know where you're getting an exception, you can catch it and throw a different one that you do stop on – Caius Jard Nov 03 '20 at 08:22
  • Thanks for the responses. I don't think you understand what I am trying to do. I don't want to eliminate one specific type of exception. I want to eliminate one Instance of a type of exception. – Matt Fitzmaurice Nov 03 '20 at 12:39
  • I'm not aware of a way to do that with the exceptions window (there may be a way, I'e never looked), but I suppose if you can identify some attribute of the exception that is reliable like "it's a COMException with an ErrorCode of 81234567" then you could put a try/catch/throw around the faulting code and breakpoint the catch with a condition of "break if ex.ErrorCode == 81234567" – Caius Jard Nov 03 '20 at 13:30
  • Yes, however that approach doesn't really work. Using that approach I would only be breaking on the specific error code. I want to do the opposite. Ignore a specific errorcode and break on all others. It would also mean that any unhandled COMExceptions elsewhere in my code would be ignored. – Matt Fitzmaurice Nov 05 '20 at 00:33
  • I find it hard to believe that this hasn't come up as a requirement and been catered for by Microsoft. – Matt Fitzmaurice Nov 05 '20 at 00:34
  • So you make the breakpoint condition `break if ex.ErrorCode != 81234567` ? – Caius Jard Nov 05 '20 at 07:38
  • Any truth you can imagine can apply to a breakpoint, even `DateTime.Now.Seconds < 6` if you only want the breakpoint to work 10% of the time – Caius Jard Nov 05 '20 at 07:43