Stop DotvvmInterruptRequestExecutionException breaking in VS

[symbiogenesis]

I notice if I wrap redirects in an async method, they don't throw the exception to Visual Studio.

This approach means no IDE settings or try/catch blocks are necessary.

Are there any downsides to this approach? Could the synchronous methods in the framework be replaced to enforce this?

These little hiccups in the developer experience just add hurdles to adoption.

[exyi]

I'm not sure if I understand correctly what do you mean, IMO the debugger breaks more often on async methods, is it really caused by the async? And even if it was true, I don't like to design API to hack a bug in VS. And which method do you mean, most of the API where interruptions take place is already async.

[symbiogenesis]

hmmm, the primary thing is to get the debugger to ignore this. Async was just something that came to mind because it is what I do.

Perhaps a better way is for the Visual Studio plugin to apply the IDE settings automatically, and by default, but with an option to un-ignore the exceptions in case anyone wants them.

[exyi]

I agree that VS Extension could disable breaking on this exceptions on a first launch, so you can turn it on later, if you want. @Mylan719 ?

…

On Tue, 2017-10-10 at 14:49 +0000, symbiogenesis wrote: hmmm, the primary thing is to get the debugger to ignore this. Async was just something that came to mind because it is what I do. Perhaps a better way is for the Visual Studio plugin to apply the IDE settings automatically, and by default, but with an option to turn it off. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[acizmarik]

We had a discussion about this with @tomasherceg and we might have figured out one possible solution for this.

DotVVM extension could try to detect redirects (a specific exception has been thrown) and ask user if these exceptions should be suppressed from now on. I feel like it would not be a good idea to set such setting by default. However, if we can detect them, we could let user decide what to do about these exceptions.