Opened 14 years ago

Closed 13 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/

Change History (1)

comment:1 by Ramiro Morales, 13 years ago

Resolution: wontfix
Status: newclosed

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 a HttpRequest 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.

Note: See TracTickets for help on using tickets.
Back to Top