9

Recently I switched to ASP.NET Core and mainly I love it!

There is one annoying part though - when I have an Exception this bubbles up through all the parts of await next.Invoke() in my whole application. That means every custom Middleware or filters that use async/await.

This means I have to press continue / F5 about 8 times every time an Exception occurs. Especially while working on tricky code this is super annoying and a big waste of time and mental energy.

See this example below:

Annoying breaks

What I tried:

  • enabled Just my Code - does not solve - as this is happening in my code.
  • disable this type of exception in the Exception Settings - this does not solve my problem, because the first (yellow) I actually need.
  • fill my whole application with [DebuggerNonUserCode] - also something that I don't like to do - as there might be legit exceptions not related to some deeper child exceptions.
  • see for more information this question

Questions:

  • As Visual Studio seems to be able to differentiate between these two Exceptions (yellow and green) - is it possible to not break at all at the "green" Exceptions?
  • How is everyone else handling this? Or do most people not have 5+ await next.Invoke() in their code?
  • Any other workarounds?

UPDATE The workaround of @MichelleWang works with specific cases, but it has a lot of configuration and maintenance if you work with a lot of different or complicated projects. Usually the async / awaits are scattered over a lot of different classes. Some filters, some base projectcode, some domain code, etc.

In a way VS already distinguishes between these two types of breaks - how to just break on yellow in general?

UPDATE

Found an existing feature request - please help and upvote there:

https://developercommunity.visualstudio.com/content/idea/739876/exception-dialog-pops-up-multiple-times-for-same-e.html

Dirk Boer
  • 8,522
  • 13
  • 63
  • 111
  • How about : 1) Original exception raised (yellow) - break occurs 2) You disable this excpetion (un-tick) in ex. settings 3) Press f5 (continue) 4) opt. enable exception again ... It should save your NxF5 where N = number of middlewares propagated :) – n.prokhorov Jul 02 '20 at 22:15
  • Hi @n.prokhorov, thanks for your comment! As in some cases this would save a few clicks - this still means with every exception I have to do all these manual steps. Somehow this must be automate this right? Especially because Visual Studio already seems to distinguish between these two *types* of breaks (green vs yellow). – Dirk Boer Jul 13 '20 at 09:03

1 Answers1

2

Add a Module Name condition in the Exception Settings window so you won’t break on any exceptions thrown from others.

  • Open Debug->Windows->Exception Settings
  • Click on an exception type or category
  • Right click on that exception and choose “Edit Conditions” Or click the blue edit pencil in the toolbar

enter image description here

In my case, I set Module Name = "HomeController.cs" to enable exceptions here. enter image description here

enter image description here

Screenshot of Test

It will break here and press F5 to end debug as we expect. enter image description here

When you remove conditions of exception setting, it will recover as you. enter image description here

The microsoft doc about conditions to an exception

Break on Exceptions Thrown only from Specific Modules in Visual Studio 2017

Michael Wang
  • 3,782
  • 1
  • 5
  • 15
  • Hi @Michelle, thanks for your extended answer. I haven't had time to test this yet. It could be a "okayish" workaround. But it still needs a lot of handwork, especially when you work in a lot of projects. – Dirk Boer Jul 06 '20 at 08:22
  • Also when you have an await in a file that is "useless" (await next.Invoke()), but you also have critical exceptions where you *do* want to break when the exception occurs - there is no way to fix this with this solution. – Dirk Boer Jul 06 '20 at 08:22
  • I've upvoted your answer, but tbh I preferably looking for something *never throw on "green" exceptions* – Dirk Boer Jul 06 '20 at 08:22
  • 1
    Hi, @Drik, thanks for the follow-up and my solution is kinda limited for the specific scenario. I am also looking forward to new solution. :) – Michael Wang Jul 06 '20 at 08:36
  • 1
    Yeah, don't get how not every ASP.NET Core developer with a lot of middleware is hitting the same problems :) Thanks again for your time! At least it's already a lot better! – Dirk Boer Jul 06 '20 at 08:59
  • I've added a bounty - I'm waiting for some other answers - otherwise I'll give you the bounty at the end! – Dirk Boer Jul 06 '20 at 09:01
  • yeah, let's wait and see. – Michael Wang Jul 06 '20 at 09:09
  • I don't have VS now but I remember there is an option to filter first chance exception and second chance exception. You might be able to leverage that to ignore second chance exceptions for the specific exception type you care about. – sidecus Jul 07 '20 at 18:58
  • Hi @sidecus, thanks for your answer. I tried to look up "second chance exceptions" but it mainly seems to be related to C++ what I find. – Dirk Boer Jul 13 '20 at 11:22
  • I'll assign the bounty - but it's still a workaround (for me). If you can help me upvote this feature request it would be greatly appreciated! https://developercommunity.visualstudio.com/content/idea/739876/exception-dialog-pops-up-multiple-times-for-same-e.html – Dirk Boer Jul 13 '20 at 11:23