CODEWITHSUNDEEP
c#exceptionasp.net-core
Nikolai Samteladze
Nikolai Samteladze

Reputation: 7797

Developer Exception Page is blank if added to IApplicationBuilder after MVC

Developer Exception Page (app.UseDeveloperExceptionPage()) is blank if added to IApplicationBuilder after MVC (app.UseMvc()) in Startup.cs Configure method.

Developer Exception Page added after MVC

Developer Exception Page works fine if added before MVC.

enter image description here

enter image description here

Is this behavior intentional or am doing something wrong?

Upvotes: 2

Views: 1902

Answers (2)

Kévin Chalet
Kévin Chalet

Reputation: 42030

The behavior you're seeing is TOTALLY intentional: in ASP.NET 5, middleware are executed in the same order as they are registered.

When registering the developer exception page middleware after MVC, it has no chance to catch the exception thrown by your controller action (as it's not even invoked). The exception is thus intercepted by the server (Kestrel), that returns a 500 response, and that's why you see a "blank page".

Upvotes: 5

Victor Hurdugaci
Victor Hurdugaci

Reputation: 28425

Even though you got an answer to this, I want to post an explanation about why adding the exception middleware doesn't catch anything added before it.

So, you have a pipeline that you build with middleware. Each middleware will (usually) invoke the one added after it. So you have something like:

M1 -> M2 -> M3 -> M4 -> ... -> Mn

When a request comes in, it will go to M1 which can do the following:

  1. Pass it further.
  2. Stop.

If it passes further, then the middleware will have another chance to handle the request when it comes back. So the request goes like this:

Request | M1 | M2 | M3 | ... | Mn
--------+----+----+----+-----+---
    X   |    |    |    |     |   
       -->   |    |    |     |   
        |  X |    |    |     |   
        |   -->   |    |     |   
        |    |  X |    |     |   
        |    |   -->   |     |   
        |    |    |  X |     |   
        |    |    |   -->    |   
        |    |    |    |    --> X 
        |    |    |    |    <--
        |    |    |   <--    |       
        |    |    |  X |     |       
        |    |   <--   |     |             
        |    |  X |    |     |       
        |   <--   |    |     |       
        |  X |    |    |     |       
       <--   |    |    |     |
    X   |    |    |    |     |

Each middleware is a method call:

M1() 
   // Do something before M2
   M2()
       // Do something before M3
       M3()
           ...
       // Do something after M3
   // Do something after M2

So, if anything happens in a middleware, any middleware in front of it has the chance to react to that. Anything after, doesn't know about it. E.g. If M2 throws an exception, M1 can catch it because M2 runs in the context of M1 but M3 either was not invoked yet or has already completed.

Upvotes: 6

Related Questions