Code

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6537 closed (duplicate)

Unhelpful error message: 'tuple index out of range'

Reported by: Michael@… Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords: url error message tuple index
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

There's something evidently wrong with my urls.py, but this error message is absolutely no help in sorting it out. Please have it output which tuple it's trying to index. The error message is providing no context, and unlike normal python tracebacks it is not tied to a particular line in my urls.py.

Traceback (most recent call last):

  File "c:\django\django\core\servers\basehttp.py", line 277, in run
    self.result = application(self.environ, self.start_response)

  File "c:\django\django\core\servers\basehttp.py", line 631, in __call__
    return self.application(environ, start_response)

  File "c:\django\django\core\handlers\wsgi.py", line 205, in __call__
    response = self.get_response(request)

  File "c:\django\django\core\handlers\base.py", line 130, in get_response
    callback, param_dict = resolver.resolve500()

  File "c:\django\django\core\urlresolvers.py", line 275, in resolve500
    return self._resolve_special('500')

  File "c:\django\django\core\urlresolvers.py", line 264, in _resolve_special
    callback = getattr(self.urlconf_module, 'handler%s' % view_type)

  File "c:\django\django\core\urlresolvers.py", line 255, in _get_urlconf_module
    raise ImproperlyConfigured, "Error while importing URLconf %r: %s" % (self.urlconf_name, e)

ImproperlyConfigured: Error while importing URLconf 'reports.urls': tuple index out of range

Here's the urls.py that is evidently not acceptable, but I cannot see which tuple of tuples of tuples it is trying to index and failing on:

from django.conf.urls.defaults import *
import views as views
import settings

urlpatterns = patterns('',
    # Example:
    # (r'^reports/', include('reports.foo.urls')),
    (r'^$', views.home_page),
)

if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^images/(?P<path>.*)$', 'django.views.static.serve',
         {'document_root': 'c:/projects/djcode/reports/images'}),
        (r'^css/(?P<path>.*)$', 'django.views.static.serve',
         {'document_root': 'c:/projects/djcode/reports/css'}),
    )

Attachments (2)

6537.diff (2.8 KB) - added by guettli 6 years ago.
urlresolvers.diff (866 bytes) - added by john_scott 6 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 6 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 6 years ago by guettli

  • Cc hv@… added
  • Has patch set
  • Triage Stage changed from Unreviewed to Accepted

I can't reproduce your exception, but I know the problem. Up to now the original exception is lost.
I wrote a patch which passes the exception up to the debug view.

Please test and leave a comment.

Changed 6 years ago by guettli

comment:3 Changed 6 years ago by john_scott

I'm not sure why they are catching all exceptions on __import__() only to instead raise a generic ImproperlyConfigured exception that usually is not of any help when resolving whatever the error actually is. In my experience, I've never seen this error because of a borked urls.py, it's almost always been something messed up in a view.

I simply removed the try/except wrapping self._urlconf_module = __import__(self.urlconf_name, {}, {}, ['']) to let the actual exceptions percolate up, rather than try to hack informativeness into the generic catch-all exception. If you run into an actual import error (as the code comment suggests they are guarding against), why not just let the ImportError bubble up? All other errors need to be revealed so we can see why resolving urls bombs so mysteriously. I'll attach a quick patch, just for completeness' sake.

Changed 6 years ago by john_scott

comment:4 Changed 6 years ago by jarrow

  • Resolution set to duplicate
  • Status changed from new to closed

Closing this as a duplicate of #7524 (even if this ticket is older and had the patch earlier) as the other ticket got triaged ...

comment:5 Changed 6 years ago by guettli

  • Cc hv@… removed

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.