-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should ASGI include an equivalent to exc_info
?
#54
Comments
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? |
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. |
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? |
As it happens that’ll probably already provide the desired behaviour with ASGI servers as they’ll:
|
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) |
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) |
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:
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.
The text was updated successfully, but these errors were encountered: