Mvc: Web API needs equivalent of UseDeveloperExceptionPage

[Rick-Anderson]

It would be nice to have middleware that returned JSON error information for WebAPI projects.

1. Create a new WebAPI project and add Swagger.
2. comment out // [HttpGet]
3. Navigate to http://localhost:16489/swagger/v1/swagger.json and you get a 500 error

You can run IIS Express but you won't get any error information.

Update the values controller:

 // GET api/values/5
        [HttpGet("{id}")]
        public string Get(int id)
        {
            if (id > 5)
                throw new Exception("ID > 5");

            return id.ToString();
        }

When id > 5 you just get a 500 error in postman. It would be nice to get back error information.
@danroth27

[rynowak]

/cc @kichalla - I remember we talked about this a while back - did you end up building a sample?

[Eilon]

We have loggers that will log any errors (including the ELM prototype), and that already works today. What would be the idea here? Where does the error get displayed?

[kichalla]

@rynowak I actually do not remember discussing about this. Probably we can discuss again.

[rynowak]

@Eilon - a lot of API testing tools won't render HTML so using the developer exception page with these tools is a fail. But... API testing tools are needed, because there's tons of stuff you'll need to test that isn't easy with a browser

[danroth27]

For Web API development I think you would want an option to have the exception serialized in the 500 response.

[Eilon]

Yeah I totally understand we don't want to render HTML for an API. I just wasn't sure what alternatives people were thinking about.

[khellang]

Couldn't this just go through content negotiation like any other result, preferably by standardizing on something like Problem Details for HTTP APIs (RFC 7807)?

[rynowak]

@khellang - right now there is no result, just an exception

[rynowak]

Reading through this RFC, it's not clear to me that this should be used for something like an _exception page_ - from the document:

Problem details are not a debugging tool for the underlying implementation; rather, they are a way to expose greater detail about the HTTP interface itself.

This seems like a an attempt to standardize on a format and protocol for error messages related to the API usage or business domain.

[Eilon]

Yeah the scenario here, if I understood it, is that a "fatal programming error" happened during development. Not just the normal "the date format was wrong" type of stuff.

[MFFoX]

For now, if you don't want to rely on the logs in development, you can just catch the exception in middleware and breakpoint it:

app.Use(async (context, next) =>
{
    try
    {
        await next.Invoke();
    }
    catch (Exception e)
    {
        //<-- breakpoint
    }
});

[danroth27]

@Eilon @rynowak I don't think we've heard a lot of complaints about this. When a 500 error occurs you need something human readable in the response that tells you what the problem was when running in development. HTML is a human readable format, and many web API test clients know how to render HTML (ex Fiddler). If you're using a test client that can't render it you can just dump it into a browser.

We could consider adding some conneg support to the developer exception page that enables rendering the error details in JSON/XML/plain text. This might be easier to read in some circumstances. We would probably then need some additional options on the dev exception page middleware to specify which format you prefer. But this would be handled by the dev exception page middleware, not MVC.

If folks agree with this assessment we should close this bug and open a new one in the Diagnostics repo.

[rynowak]

I don't think we've heard a lot of complaints about this.

I don't really agree with any of this. I think this is still a pain point.

I do agree however that this should be part of the diagnostics feature set.

[Rick-Anderson]

I've had several customer complaints they are getting a generic 500 Error.

[danroth27]

https://github.com/aspnet/Diagnostics/issues/346

[danroth27]

https://github.com/dotnet/templating/issues/949

[danroth27]

I don't really agree with any of this. I think this is still a pain point.

Yeah, I've now found reports of this issue in other repos. Part of the problem is that we don't even add the developer exception page in the web API templates, so I opened an issue to add it. We should also look at making the developer exception page support a more web API friendly format.