Should ASGI include an equivalent to exc_info?

[tomchristie]

WSGI includes an exc_info, which there's no equivalent of in ASGI.

There's a couple of things this means we can't do:

• If an application framework catches exceptions and returns 500 responses (which it should) than the server framework cannot log the traceback as an error, since it never sees it.
• Error logging middleware (eg. raven) can't work if the application framework catches and handles exceptions/500.
• Test frameworks (eg. Starlette's TestClient, that plugs requests directly into an ASGI application) cannot raise the raw exception in 500 cases. (We can make sure that the application is responsible for not returning 500 responses under a test-case environment, but that ends up being a framework-by-framework approach.)

Not expecting any immediate resolutions here, but raising for consideration.

[andrewgodwin]

Right - I obviously realised this during the spec phase, but it's hard to copy WSGI here since there's no similar concept of a single return. Do you have any ideas how we might provide for this? Maybe a specific exception message type?

[tomchristie]

Do you have any ideas how we might provide for this? Maybe a specific exception message type?

I'm not sure yet, since haven't properly thought through the implications of how it ought to be handled with websockets or other cases.

[tomchristie]

Mentioning this because it occurs to me, but haven’t yet thought it through...

Perhaps applications that catch errors and return a 500 response, could send the response and then just raise the exception?

That’s not a pattern that WSGI had available, but it could be a perfectly sensible approach with ASGI?

[tomchristie]

As it happens that’ll probably already provide the desired behaviour with ASGI servers as they’ll:

1. Given that a response has already been sent they will not write a server generated 500.
2. The exception will be seen and logged by the server.

[andrewgodwin]

Yup, that seems like a reasonable enough approach, as long as servers are smart enough to not send a response when an exception happens if one has gone out already (had to fix that in Daphne recently)

[tomchristie]

Going to close this off because I think the sensible answer is “don’t use exc_info, just raise the exception”. (And it’s okay for an HTTP middleware to catch, send a 500, then raise)