reverse() should report the reverse lookup that fails.

[mrts]

Now that {% url foo %} does not fail silently any more, it's really important to report which reverse lookup failed.

Compare:

Before the attached patch:
--------------------------
Django version 1.0-alpha_2-SVN-8255, using settings 'trunk.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Traceback (most recent call last):
...
  File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py", line 291, in reverse
    raise NoReverseMatch
NoReverseMatch

After the attached patch:
--------------------------
Django version 1.0-alpha_2-SVN-8255, using settings 'trunk.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Traceback (most recent call last):
...
  File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py", line 291, in reverse
    raise NoReverseMatch("Reverse for '%s' not found." % lookup_view)

NoReverseMatch: Reverse for 'foo-bar' not found.

Run a rgrep foo-bar . and you find the offending place easily.

[Julien Phalip]

+1 on this! How strange, I was just about to file the same ticket with pretty much the same patch :)

[mrts]

Not strange at all, people will be hit by this all over Djangoland now that r8211 is in and there will be loud cries of "Help! I don't know which of my url tags is failing!" everywhere :).

I think that r8211 was a right thing though, I was able to catch an empty {% url %} I'd missed previously (but not before patching Django).

[Luke Plant]

Fixed in [8272]

[Jacob]

Milestone 1.0 deleted