How are Polly users dealing with Visual Studio wanting to break on exceptions?

[jpierson]

Since Polly is handling the retry logic for a given bit of user supplied code it would be nice to avoid the the Visual Studio debugger from breaking on exceptions that occur but then are caught in this code. I believe used to use the [DebuggerNonUserCode] to achieve this in an older project for some custom retry code but it appears that due to changes in Visual Studio 2015 this will no longer work out of the box. What are other Polly users doing to avoid the annoying debugger interference without having to custom each developer's Visual Studio settings or making custom registry hacks?

Related:

• Stack Overflow - Don't stop debugger at THAT exception when it's thrown and caught
• Stack Overflow - Is there a way to prevent Visual Studio from breaking on exceptions in a specific method?

[reisenberger]

@jpierson Are you experiencing the debugger only breaking on the final failed try (when all retries have failed), or on each-and-every try?

In my environment, with VisualStudio 2015 Update 3, and “JustMyCode” enabled:

• If Polly is retrying a user delegate several times, the debugger doesn’t break for each failing invocation, only for the final failed attempt (the one Polly rethrows if all configured retries have failed).
• The debugger throws the exception back onto (ie the debugger breaks at) the policy.Execute(()=> {...} ) (or equivalent) statement; it doesn’t break within Polly source code files like RetryEngine.cs, RetrySyntax.cs etc.

If your VStudio experience is less good than that, let’s investigate why.

---

@jpierson Assuming it’s only the rethrow of the final failed attempt that’s causing the debugger to break, you might consider using Polly’s .ExecuteAndCapture/Async(...) (if not already) in place of .Execute/Async(). .ExecuteAndCapture(...) doesn’t rethrow the final exception; instead it captures it into a property on a PolicyResult. More info here. Should be much less noisy for debugging.

[reisenberger]

Very interested to hear also any community suggestions around VStudio settings.

( @jpierson Have reviewed the SO questions you pointed to; not aware of any tricks better than suggested there )

[reisenberger]

@jpierson Did you find any better solutions on this?

[jpierson]

@reisenberger, unfortunately no.

[reisenberger]

@jpierson / anyone: Any idea whether Microsoft changed this behaviour for Visual Studio 2017? (The fact discussed here under How to Suppress Ignorable Exceptions with DebuggerNonUserCode that a performance improvement in VS2015 led to exceptions in sections marked [DebuggerNonUserCode] still breaking, ignoring the [DebuggerNonUserCode] attribute.)

@jpierson Since Microsoft are actively engineering on VS2017 RC and seeking product feedback, could be a time to report it? - if the issue still applies.

[reisenberger]

Closing due to lack of further comment/activity.

Detailed wiki article now written giving guidance on how to best configure Visual Studio for debugging with Polly, including reference back to this issue.