ProblemDetails is not returned for 404NotFound and 500Exception

Describe the bug

Given a new ASPNET Core 2.2 “API” Website, ProblemDetails are not returned when:

• the route doesn’t exist (404 Not found)
• an exception is thrown from inside an ActionMethod.

I understand that currently ProblemDetails are provided when a Controller is decorated with ApiController. So the first scenario (route doesn’t exist/match) can’t currently be handled. The second scenario (exeception thrown) is inside an Controller/ActionMethod that has been decorated.

ProblemDetails should apply globally, not just on a half-specific set of scenario’s. This breaks application-consistency.

Currently, the only workaround is to use @khellang 's ProblemDetails nuget library (part of his ‘Middleware’ repo).

Would be very helpful to either consider: a) implementing the full functionality b) just removing it because the current implementation feels inconsistent / half-complete. (NOTE: please don’t remove it! lets complete it!!)

To Reproduce

• Open Visual Studio 2018
• File -> New -> Project -> Visual C# -> Web -> NET Core -> ASP.NET Core Web Application -> API
• Edit Startup.cs. Comment out \\ app.UseDeveloperExceptionPage();
• Edit Controllers\ValuesController to (more or less) the following:

[Route("api/[controller]")]
[ApiController]
public class ValuesController : ControllerBase
{
    // GET api/values
    [HttpGet]
    public ActionResult<IEnumerable<string>> Get()
    {
        return new string[] { "value1", "value2" };
    }

    // GET api/values/5
    [HttpGet("{id}")]
    public ActionResult<string> Get(int id)
    {
        return Ok(id);
    }

    // GET api/values/notfound
    [HttpGet("notfound")]
    public ActionResult<string> Get2()
    {
        return NotFound();
    }

    // GET api/values/notfound/aaaa
    [HttpGet("notfound/{text}")]
    public ActionResult<string> Get3(string text)
    {
        return NotFound(text);
    }

    // GET api/values/exception
    [HttpGet("exception")]
    public ActionResult<string> Get4()
    {
        throw new Exception("pew pew");
    }
}

I’ve just added some specific routes to test problem details. (look below 😎 )

• Test the following routes:
  • ✅ https://localhost:7001/api/values/a (400 Bad Request)
  • ✅ https://localhost:7001/api/values/notfound (404 Not Found)
  • ❌ https://localhost:7001/api/values/notfound/aaaaaa (404 Not Found)
  • ❌ https://localhost:7001/api/values/exception (500 Server Error)
  • ❌ https://localhost:7001/api/values/sdfkdsjfhksdfh (404 Not Found and route doesn’t exist)

Expected behavior

• At any time the response is 4xx/5xx I would expect the ProblemDetails to be returned.
• Would love to have the option to specify wether exception details are included (default is not). This just helps when IsDevelopment mode.
• Assumption would be to wire this up in Startup.cs.

Additional context

.NET Core SDK (reflecting any global.json):
 Version:   2.2.100
 Commit:    b9f2fa0ca8

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.100\

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

Also using Visual Studio 15.9.4

polite cc @glennc

Thank you kindly for your awesome work and here’s Dwayne/TheRock singing sweet nothings to help persuade the decision process, here. Like, who would say ‘no’ to TheRock??

[PureKrome]

While the templates aren’t exactly wired up to do this, it does seem like there are enough building blocks to meet your goals. What do you think?

Yep - there are enough building blocks to do this. As a case in point, I did this nearly a year ago and have been using this in various .NET apps.

I guess my main request was to try and bake this more into the common template stuff. Part of the issue here was that having a webapi only handle some errors are problem-details feels like an incomplete solution. Think about it -> why would a webapi only return some errors as PD’s while other scenario’s as … not-PD’s?

So the discussion was more about having a consistent solution across a webapi template.

[PureKrome]

@nsmithdev the current, best solution IMO is @khellang 's nuget. Works great.

that said this issue is about making that functionality the DEFAULT/BAKED IN. not a 3rd party. Yes, the 3rd party nuget is awesome but the suggestion/issue hits to the core of what an API is or should be. Right now, it’s a hybrid … which feels messy and confusing. So hopefully this issue will gather some traction behind the scenes to promote a consistent message and consumer experience of “api websites”.