-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Deprecate returning web.HTTPException from handlers and middlewares #2415
Comments
I agree with motivation, but I think 1 year is too long. 3.0 should deprecate httpexception return. And turn to a hard error in half a year or 3.2 Replacing return with raise is not big change |
Btw transition to 2.0 was not that hard, but amount of changes was relatively big. |
@fafhrd91 maybe you right. But maybe a year will be good enough. Or 1.5 years. |
I would even drop instead of deprecate for 3.0. migration to 3.0 would need attention to software in any case. |
I'm +1 to drop as well. |
+1 to drop inheritance from Response |
Fixed by #2515 |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs. |
Now an endpoint might either return
web.HTTPException
(HTTPForbidden
for example) or raise it.It makes a mess, very often a middleware should check for type of response and process it as exception if the response is an instance of
HTTPException
.Deprecation could be added just before this line: https://github.com/aio-libs/aiohttp/blob/master/aiohttp/web_protocol.py#L428
Next step in transition plan is adding
HTTPException.make_response()
method.At the end we could drop inheritance from
web.Response
at all.@tailhook told me about the problem a year ago.
aiohttp.web
was designed after Pyramid framework.I still think Pyramid is much better designed than Django and Flask but the library is not such popular because alternatives acquired much better promotion.
Anyway, Pyramid inherits HTTP exceptions from both
Response
andException
classes, we did the same.Now, after years of working on aiohttp and derived projects, it's clean for me: the choice was definitely wrong.
I was not ready for such breaking change at the moment but now I have a strong feeling that the change makes sense and very important.
Sure, we should do transition smoothly: a warning and
make_response()
method could be added in next aiohttp 3.0 release butweb.Response
removal should wait for a year and half at least.Champions for first two steps are welcome!
The text was updated successfully, but these errors were encountered: