Opened 14 years ago
Closed 14 years ago
#13945 closed (wontfix)
[Enhancement] Better diagnostics when view returns rendered SafeUnicode
Reported by: | JonathanHayward | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I made the mistake of making a view return SafeUnicode returned by a renderer, instead of an HttpResponse. The error message does not make it clear to a learner that a string-like object has been returned where an HttpResponse is needed:
Traceback (most recent call last): File "/usr/local/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 280, in run self.result = application(self.environ, self.start_response) File "/usr/local/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 674, in __call__ return self.application(environ, start_response) File "/usr/local/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 245, in __call__ response = middleware_method(request, response) File "/usr/local/lib/python2.6/site-packages/django/contrib/sessions/middleware.py", line 26, in process_response patch_vary_headers(response, ('Cookie',)) File "/usr/local/lib/python2.6/site-packages/django/utils/cache.py", line 127, in patch_vary_headers if response.has_header('Vary'): AttributeError: 'SafeUnicode' object has no attribute 'has_header'
This is not quite as informative as a usual Django error page. Perhaps error handling could give friendlier diagnostics if a view returns something string-like when it should return an HttpResponse?
Jonathan
http://JonathansCorner.com/
Note:
See TracTickets
for help on using tickets.
I think it is clear from the traceback your code is providing a using a
SafeUnicode
instance where. The fact that a basic view needs to return aHttpRequest
is a basic well covered in the tutorial and topic documentation.Second, IMHO if Django had to implement handholding the programmer to help him/her to avoid every type mismatch it would a bloated mess and would negate the advantages of using a dynamically typed language and duck typing.
Also, there are third party solutions that allow views to return context contents instead of a HttpResponse, so hardcoding such a type check could be detrimental to them.