Code

Opened 4 years ago

Closed 3 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: UI/UX:

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/

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by ramiro

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.