-
Notifications
You must be signed in to change notification settings - Fork 881
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Change in Exception views handling should be reflected by docs #3670
Comments
Coworker of @Sim175 here. Here's a minimal Pyramid project to reproduce the issue:
We don't disagree with how Pyramid handles things but prior to 2.0 this pattern used to work and the documentation suggests that it should. |
If you are relying on this behavior and you are not using Here is an example #3468 (comment) that shows how to create your own execution policy. We could be more explicit in the documentation that exception views should return a valid response object, and exceptions raised from an exception won't be handled again. All the examples of exception views show the view returning a response already. Related: #3468 |
I can't think of a situation where a view couldn't be trivially changed to just use
I think that this is exactly what is needed. Just doing that would prevent errors in usage as I didn't find anywhere where it was mentioned that exception views should behave differently than other views. These are the places where I feel that this information should be added: |
Ever since commit f9813e0, the default behavior is to let exceptions raised within exception views bubble up instead of attempting to handle them until a Response is returned. For example, you could previously expect to be able to raise HTTPFound in your HTTPForbidden handler to redirect to a login page; but now, the HTTPFound exception goes all the way up and causes a 500 error to be produced instead.
However, the docs still indicate that you should always be able to
return
orraise
an HTTPException in any view callable :Specifically, the second example provided here (
raise
) wouldn't work in exception view code, while the first example (return
) would produce a 302 response.Suggestion: mention that exception view code should only
return
HTTP exceptions unless the default execution policy is overridden.The text was updated successfully, but these errors were encountered: